Software Guru CONOCIMIENTO EN PRÁCTICAdesquer.ens.uabc.mx/afi/articulos/SG05_5_sep_oct.pdf · • Conﬁabilidad del Software • ebXML • Administración con Cadena Crítica Software

• Confiabilidad del Software

• ebXML

• Administración con Cadena Crítica

Software Guru CONOCIMIENTO EN PRÁCTICA

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

S

epti

emb

re-O

ctub

re20

05

Año 01 No.05 • Septiembre-Octubre 2005 • www.softwareguru.com.mx ENTREVISTA:Rafael FunesDirector de Dynaware

MIPS para llevarDesarrollo de Aplicaciones Móviles

CASO DE ESTUDIO:Pruebas Controladas de MoProSoft

Inteligencia ArtificialBase Tecnológica delas Empresas

PROGRAMACIÓN:J2ME

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

Año

01

No.

05

DIRECTORIO

02 SEP-OCT 2005 www.softwareguru.com.mx 03SEP-OCT 2005www.softwareguru.com.mx

Edición EjecutivaPedro Galván

Coordinación EditorialMara Ruvalcaba

Edición y ProducciónEdgardo Domínguez

Dirección de ArteOscar Sámano

IlustraciónLuis Pérez

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

ColaboradoresAriel 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

[email protected]+52 55 5239 5502

Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de tí-tulo: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en agosto de 2005 en Litográfica Roma. Distribuido por Sepomex.

“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 afirmaciones 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 platafor-mas y perspectivas, para darles un panorama lo suficientemente amplio. Espera-mos que sea de su agrado, pero sobre todo que les sea de utilidad.

Estamos muy orgullosos porque ya tenemos Norma Mexicana de Software. Esta-mos 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 nego-cio de la mayoría de las empresas mexicanas de software gira alrededor de pro-veer 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 pre-side 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 retroalimenta-ción y comentarios a través del sitio web, o en [email protected]

Equipo Editorial

A >

EDITORIAL

contenido sep-oct 2005 número 05

Productos

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

NOVEDADES 12Windows Vista

Prácticas

PROGRAMACIÓN 32Java 2 Micro Edition (J2ME)Víctor Quijano nos enseña como hacer un "Hola Mundo"en J2ME.

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

ADMINISTRACIÓN DE PROYECTOS 38Cadena CríticaMartín Olguín comparte los secretos de laadministración de proyectos utilizando cadena crítica.

PROCESOS 40De SW-CMM a CMMIMariana Perez-Vargas nos habla sobre CMMI y la transición desde SW-CMM.

ASEGURAMIENTO DE CALIDAD 42Confiabilidad del Software¿En qué consiste la confiabilidad del software?¿Como se mide? Esto y más nos responde ungrupo de investigadores del CIMAT.

Columnas

Tejiendo Nuestra Red 06por Hanna Oktaba

Mejora Continua 08por Luis Cuellar

Prueba de Software 49por Luis Vinicio León

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

En Cada Número

Noticias y Eventos 04UML 46Fundamentos 48Tecnología 50Carrera 56


Entrevista 18 Rafael Funes, Director de Dynaware

Caso de Estudio 28 Pruebas controladas de MoProSoft

EN PORTADADesarrollo de Aplicaciones MóvilesElementos a considerar en el desarrollo de software para PDAs y teléfonoscelulares: tecnologías, plataformas y perspectiva de la industria.

20Inteligencia Artificial 14 Base Tecnológica de las Empresas


NOTICIAS

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, aca-demia y entidades de gobierno.

Durante el evento se contó con expo-siciones 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 empre-sas 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

ProSoft

El 12 de agosto Aguascalientes fue anfitrión del Evento “Mejores prácticas del ProSoft y el De-sarrollo 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 Aguasca-lientes”, Innovatia, con la presencia de Sergio Carrera Riva Palacio, Director General de Comer-cio 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, Oaxa-ca, 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 ofre-cimiento para las Pymes; y, los canales de distribución. La segunda parte del evento fue la pre-sentació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.

XpoLinux 2005Del 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 proce-samiento masivo de información.

Entre otros conferencistas presentes, estuvieron Carlos Muñoz, de Linux Center Latinoamérica, Alfredo Santana, quien habló so-bre los nuevos Centros de Soluciones Linux, y Jose Luis Chiquete de la Asociación Mexicana de Software Libre.

Noticias

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 desarro-llo 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


Eventos

12 al 15 Octubre 2005XXVI Convención Nacional Anual CANIETIHotel Presidente Intercontinental. Monterrey, NLInfo: www.canieti.org Tel: 01 (55) 5264 0808e-mail: [email protected]

17 Octubre 2005Directions 2005 – IDCWorld Trade Center, Cd. de MéxicoInfo: www.idc-eventos.com/directions05 Tel: (55) 5523 9910

18 y 19 Octubre 2005Congreso AMITI 2005 – TI Evolucionando los NegociosWorld Trade Center, Cd. de MéxicoInfo: www.congresoamiti.com Tel: (55) 5523 9910

23 al 26 Octubre 2005II Conferencia Latinoamericana de Interacción Humano-ComputadoraITESM, Cuernavaca, MorelosInfo: www.clihc2005.org e-mail: [email protected]

26 al 28 Octubre 2005XVIII Congreso Nacional y IV Congreso Intl. de Informática y Computación ANIEIUniversidad Autónoma de la Laguna. Torreón, CoahuilaInfo: www.aniei.org.mx Tel: (871) 729 0101e-mail: [email protected]

5 y 6 Septiembre 20051ra. Cumbre de Gobierno y Tecnología – IDCCentro Banamex, Cd. de MéxicoInfo: www.idc-eventos.com/cumbregobierno05Tel: (55) 5661 - 3791e-mail: [email protected]

17 al 22 Septiembre 2005Oracle Open WorldMoscone Center. San Francisco, CaliforniaInfo: www.oracle.com/openworld e-mail: [email protected]

21 Septiembre 2005IP Business Communications Conference 2005 - IDCCentro Banamex. Cd. de MéxicoInfo: www.idc-eventos.com/ip05Tel: (55) 5661 - 3791e-mail: [email protected]

26 al 30 Septiembre 2005Encuentro Internacional de Ciencias de la ComputaciónUniversidad Autónoma de Puebla. Puebla, MéxicoInfo: www.enc.smcc.org.mx Tel: (222) 229 21 38e-mail: [email protected]

7 Octubre 2005Seminario Admón. Integral de TI con ITIL y Creando una Oficina de Proyectos Práctica y EfectivaItera. Cd. de MéxicoInfo: www.itera.com.mxTel. (55) 5281 7670e-mail: [email protected]

Lanzamiento de TI Sonora

En las instalaciones del Instituto Tecnológico de Sonora, Alber-to 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 univer-sidades 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

por los egresados de las universidades locales. Mencionó que varias de las empresas que integran la asociación ya están ex-portando software, y que se tienen alianzas con empresarios de Arizona, con quienes comercializan productos y servicios rela-cionados con el software.

De acuerdo con un estudio realizado por la Secretaría de Econo-mí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

El 5 de julio fue aprobada por el NYCE la norma mexi-cana Tecnología de la Información-Software-Mode-los de procesos y evaluación para desarrollo y man-

tenimiento 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: Di-rectrices 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 obli-gació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 echar-le 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 Work-shop 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 em-presas (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 de-finir un marco metodológico común de procesos y su eva-luación para la industria de software de esta zona. Para mi sorpresa, los argentinos, españoles, chilenos, venezolanos, brasileños, colombianos, paraguayos y ecuatorianos quie-ren 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 Ibero-americano de CYTED (Ciencia y Tecnología para el Desarro-llo) 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ó MoPro-Soft cuando lo presenté en el evento de SEPG LA en Guada-lajara en noviembre pasado, me mandó un mensaje desde Helsinki. Resulta que en esta bella y tranquila ciudad, se

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 Profi-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 parti-da para este trabajo. No tengo que explicarles que me que-dé 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 ha-bas 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 Mo-ProSoft en Mexicali. A pesar de muy altas temperaturas, encontré un entusiasmo y una dedicación sorprendente. Los participantes provenían del triangulo bajacalifornia-no Mexicali-Tijuana-Ensenada y representaban a la aca-demia, 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 reflejado en las actividades diarias y en los am-biciosos planes del Cluster de TI de Baja California, diri-gido 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 de-sayuno con los empresarios y académicos de Ensenada, volvió a escuchar mi plática en una reunión con mis cole-gas 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

CO

LUM

NA

06 SEP-OCT 2005 www.softwareguru.com.mx

MoProSoft Nuestra Ventaja Competitiva

TEJIENDO NUESTRA RED

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

TEJIENDO NUESTRA RED

La 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 complemen-tarlo con ideas propias. La información que obtuve fue muy va-riada, 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 exi-tosamente, para poder enseñar a otros como hacerlo. Esto es comprensible, sin embargo hay que cuidar lo siguiente:

a) Ser responsable de un cambio organizacional es más una labor de venta que una labor de administración. El tra-bajo es mucho menos de dirigir y mucho más de influen-ciar.

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 ha-cia 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 cali-dad, debido a su gran conocimiento. Pero su nivel de entrega a la perfección en ocasiones los lleva a definiciones muy rígi-das. Es muy fácil defender un modelo porque está publicado en un libro o porque la industria dice utilizarlo, pero en gene-ral la realidad es mucho más complicada que la teoría.

3. Estudioso y apasionado de su trabajo. Existen muchos mo-delos 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 man-tener un balance entre lo que se aprende y lo que se aplica.

Agentes de CambioLo 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 mo-delos y metodologías de mejora. Además de los puntos ante-riores, 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

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 res-puestas, y debe estar conciente de esto. Su labor es de con-ciliació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 organiza-ción en forma exitosa dando un resultado mejor al anterior.

3. Habilidad para escuchar y ser flexible. Esta es posible-mente 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 perse-verancia, 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 escu-cho 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 melan-colía; ya que lo que dejamos atrás es parte de nosotros mis-mos; 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 pre-gúntate como ves tu rol, ¿eres la persona con todas las res-puestas, que va a corregir a los demás?, o ¿eres un Agente de Cambio? Alguien que ayuda a su organización a crear una nue-va vida y dejar atrás la anterior para que descanse en paz.

- Luis Cuellar

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


CO

LUM

NA

Agentes de Cambio de CalidadAcerca de Héroes y Agentes

MEJORA CONTINUA

MEJORA CONTINUA


PR

OD

UC

TO

S

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 co-nexión se reestablece. Todo esto se realiza de manera transparente y sin intervención del usuario.

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

El Tivoli CDP estará disponible en Estados Unidos a partir de la segunda mitad de sep-tiembre 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

Tivoli CDPProtección Automáticade Información

IBM lanzará un nuevo producto para protección de datos, lla-mado 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 recu-perar el estado de sus archivos en cualquier punto del tiempo, protegiéndose así de pérdidas de información por virus, corrup-

PRODUCTOS

Red Hat NetworkAdministració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 ope-rativos, 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 aplica-ciones 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 he-terogéneos con un solo producto.

LO QUE VIENE

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

Durante su conferencia Tech Ed 2005 en Orlando, Microsoft final-mente 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 desarro-lladores. 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 aplica-ciones 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 de-sarrolladores: msdn.microsoft.com o la versión en español: www.microsoft.com/spanish/msdn/

PR

OD

UC

TO

S

Windows VistaPanorama para los DesarrolladoresPor Luis Daniel Soto

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

E l escuchar “Windows Vista” (anteriormente conocido con el nombre clave Longhorn), pro-ducirá en el lector un gran escepticismo. De

forma análoga, si nos recomiendan un “buen vino”, no importa la abundancia de alabanzas que nos mencio-nen... 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: confia-bilidad, privacidad, seguridad, respuesta.• En segundo lugar, hay numerosas áreas de innovación tanto para el desarrollador como para el usuario final.

Los FundamentosEl beta 1 de Windows Vista es primariamente para de-sarrolladores de software —más de 250 nuevas caracte-rí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 in-terferir en la experiencia del usuario. Hay nuevas APIs para envío de comentarios de usuarios y para instrumen-tació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 Windo-ws, 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 refe-rente a capacidad de generar imágenes para instalación masiva, migración de instalaciones, descubrimiento del

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 compatibi-lidad con aplicaciones y drivers superior al noventa y cinco por ciento.

Mayor control en redes compartidas.

Desarrollo de SoftwareConstruir software para Windows Vista significa poder tomar ventaja de:• Plataforma Windows Vista. No sólo los fundamen-tos, sino también los nuevos servicios de la platafor-ma: instalación mejorada, funcionalidad peer-to-peer, quality of services (QoS), administrador de sincroni-zaciones, 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, per-mite crear aplicaciones muy atractivas visualmente.


NOVEDADES

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

www.softwareguru.com.mx

NOVEDADES

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

Se compone de una maquinaria y un fra-mework con nuevos controles y extensibi-lidad: 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 tec-nologías actuales de cómputo distribuido para crear sistemas conectados en forma consistente, software orientado a servicios. Habilita la creación de experiencias basa-das en servicios web compuestos.• Aero. Es una nueva filosofía para el di-seño de aplicaciones, incluye una interfaz de programación para ayudar a los desa-rrolladores a crear una experiencia emo-cional más fuerte con usuarios finales: permite manipular los controles del siste-ma operativo y el administrador integrado de ventanas.

Capacidad de correr múltiples videos simultáneos

con texto y formas irregulares.

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

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 documen-tación que facilita la creación de aplicacio-nes y aumenta la calidad del software que se escribe.

Algunas tecnologías planeadas original-mente para Windows Vista se pueden uti-lizar 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 gradual-mente, pero estarán únicamente dispo-nibles para Windows Vista. Tal es el caso del almacenamiento altamente descripti-vo (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.

Organización de archivos por diferentes criterios.

ESPECIAL

En todas las actividades productivas, las empresas líderes obtienen ventajas competitivas a través de la investiga-ció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 ArtificialBase Tecnológica de las Empresas Desarrolladoras de SoftwarePor 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 di-nero que los competidores. Los siguientes ejemplos ilustran las ventajas que diversas empresas han obtenido al aprovechar su base tecnológica.

• La institución financiera KPMG International enfrentó (como muchas otras) la necesidad de automatizar el proceso de re-visió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 estafa-dores utilizando el sistema NORA (Non-Obvious Relationship Awareness) que busca conexiones entre jugadores, trabaja-dores 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 frecuen-temente 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 (Proto-type Optimization Model), que reúne reglas para coordinar,


planear y presupuestar los programas de prue-ba de prototipos. POM ahorra hoy a Ford más de USD 250 millones al año.Todos estos de-sarrollos han producido beneficios probados y cuantificables aplicando técnicas de Inteli-gencia 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 espe-cíficas como la visión, el lenguaje, el reconoci-miento 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 considera-bles 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 pre-senta sus componentes y demuestra la via-bilidad 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ógicaLa 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.– Refle-jan 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 acumula-da en el desarrollo y explotación de tecnología. Una evaluación detallada de las ventajas tec-nológicas esenciales debe distinguir entre las tecnologías de producto y de proceso. Una cla-sificación útil para las ventajas tecnológicas es

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 opor-tunidad de lograr una diferenciación significa-tiva 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 ac-ceso a ellas. Por ejemplo, todas las empresas de software tienen acceso a lenguajes de pro-gramación, compiladores, ambientes de desa-rrollo, 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 emergen-tes 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 fac-tores que permiten a la empresa crear y ex-plotar 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 diferen-ciadores que con el tiempo se volverán clave.• Ventajas complementarias.– Aquí se in-cluyen disciplinas como mercadotecnia, dis-tribución, manufactura, servicio al cliente. Aunque pueden no representar propiedad

intelectual en el mismo sentido que una pa-tente o un registro, son decisivas para el éxi-to comercial de las empresas, y también se benefician de la aplicación de AI. Por ejem-plo, 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 asig-nació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 apo-yar de manera importante a la mercadotec-nia. El autor realizó un estudio de este tipo para una pequeña industria química [2].

Evidentemente, la labor de las empresas de-sarrolladoras de software consiste en crear programas para automatizar las ventajas com-plementarias, organizacionales y los procesos de desarrollo de sus clientes. Sin embargo, la gran ventaja de los desarrolladores de soft-ware 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 re-presentan valor real para sus clientes.

Figura 2. El ambiente de negocios de las empresas de

software. VTE – ventaja tecnológica esencial, VE – ven-

taja externa, PD – procesos de desarrollo, VC – ventaja

complementaria, VO – ventaja organizacional.


ESPECIAL

Las Funciones de la Inteligencia¿Qué ventajas concretas ofrece AI a las empresas desarrolladoras de soft-ware? 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 eli-minan virus informáticos, por citar tan sólo dos ejemplos. IBM, que se ha transformado de fabri-cante 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 em-plean redes neuronales que generalizan apren-diendo a partir de ejemplos de virus conocidos.• Manejo de situaciones complejas.– Todos los seres humanos estamos envueltos en ambien-tes complejos y cambiantes, por lo que es im-portante desarrollar herramientas para apoyar la toma de decisiones de los líderes de las orga-nizaciones. 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 ambien-te, terrorismo, etc. • Resolución de problemas con información faltante.– Rara vez conocemos toda la infor-mación relacionada a un problema antes de resolverlo. Todos los días nos topamos con si-tuaciones 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 inteligentemen-te 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 in-deseables.– Dada la complejidad de las mo-dernas plantas industriales, la información producida por los sistemas de control se ha vuelto difícil de interpretar con la velocidad re-querida. Por ello, se han aplicado técnicas de reconocimiento de patrones a los datos produ-cidos por estos sistemas para identificar fallas antes de que éstas ocurran, lo cual ha gene-rado 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 patro-nes visuales u objetos con la misma facilidad que los seres vivos. Sin embargo, existen nu-merosas 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 organiza-ción del correo del servicio postal del mismo país, que “lee” las direcciones de los destina-tarios escritas en los sobres de las cartas.• Procesamiento simbólico.– Existen progra-mas que apoyan a los matemáticos en ma-nipulaciones simbólicas, como por ejemplo General Problem Solver (GPS) de la Universi-dad 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, secuenciamien-to 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 de-finitivamente sí resuelven problemas prácticos que las empresas y los gobiernos enfrentan todos los días, y automatizan actividades es-pecíficas que comúnmente se asocian con la inteligencia. Por ello, AI es un área de la inge-niería en constante desarrollo y que beneficia directamente a la industria del software, como han demostrado los ejemplos expuestos.

Pensando en el FuturoLas empresas líderes en el desarrollo de soft-ware (como en todas las actividades producti-vas) 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 ven-taja 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 decisio-nes y producir ahorros cuantificables.Todos los desarrolladores de software compi-ten 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 aplica-das e ingeniería de sistemas, pues con ellas es posible lograr diferenciación real ante la com-petencia de cualquier país.

Referencias• [1] Shenhar, A.J. y Adler, P.S. La base tecnológi-ca 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 in-formation 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 Ar-tificial 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.


ENTREVISTA

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 backgroundMi 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 requeri-mientos de materiales (MRP). Vi que había una oportunidad de ne-gocio 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

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 proce-so 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 orde-nada, 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.

RAFAEL FUNESDirector General de Dynaware


19SEP-OCT 2005www.softwareguru.com.mx

¿Es mejor arrancar tu empresa desde un inicio, o primero ser empleado y posterior-mente 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 em-prendedor es mejor, y no ser emprendedor es algo malo. Ambos cumplen un rol. Por cada emprendedor, se necesita una buena canti-dad de personas que se sumen al enfoque y visión del emprendedor, y que estén dispues-tos 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 re-solver la parte final del proyecto 1, eran subsi-diados 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 me-dida no era muy fácil de acotar, sobre todo en ese entonces. Así que el último 3% del proyec-to 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ára-mos terminar los proyectos, a mí me molesta-ba que el círculo no quedara cerrado como yo quería. Entonces decidí que mi única alternati-va 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 an-tes de pelearlas”. Así que mi camino fue: hago un producto que funcione bien, lo entrego, y el cliente no me puede cuestionar el produc-to, 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 instrumenta-ció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

que el negocio está en hacer algo repetible. Para entonces yo ya estaba orientado a pro-ducto, así que siguiendo su consejo me en-foque 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 mo-dificar el código. En lugar de construirle la mis-ma función a cada cliente de formas distintas, construyes una función que contiene las varian-tes 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 proyec-tos donde el promedio de nuestros competido-res 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 malin-chismo. 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 cuestio-nar ese malinchismo, especialmente en ciertos segmentos. No es un nacionalismo trasnocha-do de “me enredo en la bandera y me aviento”, o “me tomo cuarenta tequilas porque soy mexi-cano y muy macho”. No es eso, es un naciona-lismo 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 gene-ral, 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 cul-tura 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á ha-ciendo 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 cultu-ralmente 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 per-demos. Por más que se generen incentivos e infraestructura, si no resolvemos este pro-blema 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 aso-ciaciones de su industria. Yo me he involu-crado 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 per-mite 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 sus-tancialmente y sean exitosas sin meter una parte del tiempo, dinero y esfuerzo a contri-buir 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 pe-diría a los lectores de SG, que confíen en sí mismos y en los demás mexicanos.

“Mi única alternativa era hacer un producto incuestionable, matar el cuestionamiento de origen”

20

EN PORTADA

DESARROLLO DEAPLICACIONES MÓVILES

Elementos a ConsiderarPor 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 dispositi-vos 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.


El primer ámbito donde han venido sur-giendo soluciones empresariales muy interesantes es en las aplicaciones ver-

ticales. Algunos ejemplos concretos son: auto-matizació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 proporcio-nar 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 funcio-ne sobre dispositivos móviles.

ConectividadUna solución móvil en una empresa jamás es una solución aislada. Normalmente es una extensión de los sistemas empresariales exis-tentes, como ERPs o CRMs. Por lo tanto, es fundamental entender las opciones de conec-tividad disponibles en el mercado y el impacto que tienen en nuestra posible aplicación.

En primer lugar, podemos clasificar las aplicacio-nes móviles en línea y fuera de línea. Una aplicación fuera de línea es aquella que se sincroniza median-te 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).

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

En los demás patrones, lo más recomen-dable 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 co-nexión a la mano.

Sincronización de DatosPrecisamente para una aplicación ocasional-mente conectada, se vuelve crucial contar con una buena estrategia de sincronización de da-tos. 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 Stu-dio. 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, par-ticionan nuestra base de datos maestra para cada usuario móvil, y se encargan de replicar los cambios entre el servidor y los dispositi-vos 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 nues-tros sistemas empresariales.

SoportePor definición, es muy probable que nuestros usuarios se encuentren dispersos geográfica-mente 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 cos-tosas, elevando innecesariamente el costo total de propiedad de la solución.

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

Interfaz de UsuarioUno de los errores más comunes cuando un programador que viene del mundo de las computadoras personales aborda un proyec-to para dispositivos móviles, es subestimar las diferencias en la interfaz de usuario. Los dis-positivos 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 de-bemos 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 mini-mizar el número de entradas que deba hacer el usuario, aprovechando los métodos de en-trada 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.

PlataformaLas plataformas más comunes para desarrollo de aplicaciones móviles son J2ME (Java 2 Mi-cro 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 desarro-llo 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 DesarrolloLas opciones de IDE dependen de la elección de plataforma: CodeWarrior es una herramien-ta 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 automatiza-ción basados en tecnología .NET. Héctor también es Microsoft MSDN Regional Director y Microsoft MVP para Windows Embedded. [email protected]


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

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.

Código AdministradoCódigo administrado es un término que describe al código de una aplicación que corre o se ejecu-ta bajo un ambiente administrado. Esto significa que el código de la aplicación no corre directa-mente 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 adminis-trada 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 AdministradoCódigo no administrado es aquel que al com-pilarse genera un binario que es ejecutado directamente por la máquina, fuera de algún ambiente de ejecución, y que por ende no ob-tiene 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 necesaria-mente, es sólo que si el desarrollador requiere de estos servicios, debe de hacer peticiones explici-tas 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 pre-gunta, todo depende de las necesidades es-pecí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

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: me-jora en la productividad.

Sin embargo, existen desarrollos que solamente pueden ser implementados como código admi-nistrado, como es el caso de los controladores de dispositivos (device drivers).

Si por la naturaleza del proyecto es impo-sible 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++ inte-rop pueden ser de utilidad en este caso.

En cuanto a desempeño de la aplicación se re-fiere, 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 EsquemasEn el caso de la plataforma .NET, tradicional-mente los desarrolladores han requerido de una herramienta para código administrado, y otra para código no administrado. Siendo Visual

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 desa-rrolladores. Además, esta herramienta incluye la nueva versión de .NET Compact Framework (ver-sión 2.0), un ambiente de ejecución mejorado y con mayores capacidades.

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

EN PORTADA


Código Administrado yNo AdministradoUna Visión GeneralPor Óscar Esqueda

Figura 1.– Diferencia entre esquemas

ConclusiónSeleccionar un esquema de codifica-ción para implementar una aplicación es, sin duda alguna, una tarea impor-tante. Esta selección puede ser de gran influencia en la buena o mala acepta-ción de nuestro producto.

En general, la tendencia va hacia esque-mas de código administrado, ya que permiten a los desarrolladores imple-mentar 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 depen-de básicamente de los requerimientos específicos de la aplicación y de los re-sultados que esperamos obtener; resul-tados asociados a factores tales como el desempeño, la seguridad y el buen ma-nejo de los recursos.


Recientemente estuvo en México Sean Malo-ney, 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ónLa industria de TI da por hecho las conexio-nes estandarizadas y a bajo costo. Por ejemplo, en el caso de Ethernet, todo mundo da por hecho que una computadora tiene un puer-to 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 tie-nen Internet de banda ancha. La forma de re-solver este problema es desarrollar un estándar que pueda ser producido en masa, y así alterar la ecuación de costo radicalmente. Lo que ne-cesitamos para los próximos quince años, es un equivalente a Ethernet, pero en el aire.

Espectro de Frecuencia y RegulacionesLa asignación del espectro de frecuencia es un tema de gran importancia. Tarde o tem-prano todo mundo estará conectado al In-ternet, y esto sucederá a través del espectro de frecuencia. Así que es un tema de impor-tancia social, no sólo tecnológica. En Méxi-co, estamos trabajando junto con la SCT

Sean MaloneySiguiendo el Paso de los MIPS

y COFETEL facilitándoles información y experiencia de otros países, para que pue-dan tomar la mejor decisión. Una discusión que tenemos actualmente en varios países, incluido México, es que se pretende regu-lar en base a tecnología. Por ejemplo, “este espectro se va a utilizar para cierta tecnolo-gí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 conec-te 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”.

Killer ApplicationsLas 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 pen-sando en ello. Conforme hay mayor estandariza-ció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 desa-

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

Tecnología vs. AplicacionesLo 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 se-sió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 pro-cesamiento. Al graficar esto, nos dimos cuenta que la cantidad total de procesamiento que se fabricaría en 1995, sería igual al total acumu-lado 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 trae-rán consigo una buena cantidad de poder de pro-cesamiento, 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 su-piera que el usuario siempre estará disponible?”.

Mensaje para Lectores de SGEn 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..

Porcentaje de procesadores para dispositivos móviles.

EN PORTADA


Actualmente el número de líneas celulares en México asciende a 60 millones, con un incre-mento 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 defi-nición, mayor almacenamiento, etc. En este artícu-lo, 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 algu-nos puntos importantes a considerar.

Tecnologías para Transmisión de DatosEn el mundo, la tecnología predominante de los operadores celulares es GSM, un están-dar desarrollado en Europa que permite la transmisión de datos a una tasa promedio de alrededor de 8Kbps. En contraparte, los nor-teamericanos desarrollaron su propio estándar: CDMA One, que ofrece capacidades similares a GSM. Conforme los servicios de valor agre-gado fueron tomando el lugar que actualmen-te 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 mues-tra la evolución de estos estándares:

Software para Teléfonos Celulares

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

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

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.

J2MEJ2ME (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 tecnolo-gí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 ne-gocios 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 mode-los 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 recur-sos del teléfono. Además de las clases estándar del MIDP, existen “clases opcionales” que per-miten 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.

GPRS EDGE WCDMAGSM 114 kbps 384 kbps 2 Mbps

CDMA 2000 CDMA 2000 CDMA 2000 1X EV-DO EV-DV

CDMA 114 kbps 2.4 Mbps 3.1 Mbps

23JUL-AGO 2005www.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, Moto-rola, Sony-Ericsson, entre otras, cuentan con sitios para desarrolladores, donde es posible descargar especificaciones técnicas, emulado-res 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 distri-bución, es decir, dentro de las funcionalidades que ofrece BREW se tiene el kit de desarrollo de software (SDK), para la creación de aplica-ciones, 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 indepen-dientemente.

El SDK que BREW ofrece se encuentra basa-do 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 interac-tuar con los recursos del teléfono, como pan-talla, teclado, audio, conexiones, sistema de archivos, etc. El sistema de distribución y tari-fa 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óxi-mamente Unefon lo agregará a sus servicios. Hace dos años se formó en la Facultad de In-geniería de la UNAM un laboratorio de desa-rrollo 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 dis-tribuida para los usuarios de 3G de Iusacell.

Consideraciones al Crear una AplicaciónAlgunos 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 ópti-ma todos los elementos gráficos para que sean

ConclusiónEn un futuro próximo, hablando de re-des de datos, la necesidad de clientes ro-bustos 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 entrete-nimiento e información, como consulta de noticias, información de tráfico, bus-cador de calles y lugares, comercio móvil (M-Commerce).

Las herramientas de desarrollo existen, el conocimiento en programación so-bra, 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.

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 dimensio-nes. Esto es aconsejable, sin embargo, no siempre es posible.• Teclado. La interacción con el usuario se hace mediante las teclas tanto alfanu-méricas como los llamados SoftKeys, que están junto a la pantalla, por lo tanto se deben considerar todos los eventos cuan-do 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 nue-vos con memorias externas.• Conexión de datos. Las conexiones de da-tos 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 dispositi-vo móvil y un servidor, debe considerarse el ancho de banda del medio y procurar sola-mente enviar la información más relevante, pensando en tiempo y dinero del usuario.

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ícu-lo echamos un vistazo a estas tecnologías y la forma en que se utilizan para desarrollar apli-caciones para dispositivos móviles.

WAPEl Protocolo WAP (Wireless Application Pro-tocol) fue diseñado para mostrar contenido Internet en dispositivos inalámbricos, espe-cialmente 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 (Wire-less 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 No-kia. Actualmente, y aproximadamente desde el año 2002, el WAP Forum no trabaja más como organización independiente, y se con-solida como el Open Mobile Alliance (OMA), el cual es encargado de regir la especificación 2.0 de WAP y sus aplicaciones por área fun-cional, entre las cuales están:

WMLWML (Wireless Markup Language) es el len-

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

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 apli-cació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.

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 pue-den 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 WMLLas 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 In-ternet, 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 mi-cronavegador, 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ódigoLa primera línea es la especificación del tipo de documento, en este caso, XML 1.0. Pos-teriormente 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 defi-nició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 WAPEs 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 corpo-rativa a través de su pantalla.

EN PORTADA


WAP y WMLEl Dúo DinámicoPor Jorge Jasso

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.

ÁREA ESPECIFICACIÓN WAP 2.0FUNCIONALArquitectura Wireless Application Protocol Architecture Specification

Multimedia Messaging Service Architecture OverviewMultimedia Multimedia Messaging ServiceMessaging Client Transaction SpecificationService Multimedia Messaging Service(MMS) Client Transaction SIN 101 Multimedia Messaging Service Encapsulation Specification

DesventajasLa primera desventaja a destacar en la co-municació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 pro-veedor del servicio; y en el caso de aplicacio-nes empresariales, a través de los servidores de la empresa, a los que se accede por Inter-net (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 presenta-ción, además de la ya citada poca potencia de

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.

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

Portales WAPEl auge de los portales WAP está aún por venir, no hay muchos actualmen-te, dadas las limitaciones de los equipos celulares en cuanto a presentación. Los portales WAP se están enfocando a pro-veer funcionalidad limitada de un portal http, así como para ocio y diversión. Al-gunos ejemplos de portales WAP son:

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 si-tios, su celular debe contar con acceso a Internet vía GPRS (General Packet Radio Service).

CASO DE ESTUDIO

Proyecto de Pruebas ControladasPodrí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 Mo-ProSoft. La parte fundamental de este proyecto fue la participación de las cuatro empresas mexicanas seleccionadas: Magnabyte, E-Ge-nium, Arquitectura en Tecnología de México (ARTEC), y Sistemas de Gestión Administrativa (SGA).

Estrategia de Implantación de MoProSoftPor 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 capaci-dad 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

arriba del resultado que se obtuviera en el diagnóstico inicial.• La definición de las reglas de ajuste de los procesos. Se utiliza-ron los procesos de MoProSoft como base, se establecieron las secciones del proceso sobre las cuales podrían hacer adaptacio-nes, así como recomendaciones de ajustes genéricos que aplica-ban a todos los procesos.

El siguiente elemento fue definir el Plan de Procesos y el Plan Gene-ral de Implantación que utilizaríamos. En estos documentos se esta-bleció 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 Ne-gocio, 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: Ad-ministració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 pilo-to, que les permitiera empezar a ver resultados a corto plazo.Posteriormente para poder ligar la operación con la administración, se defi-nió Gestión de Proyectos, y el proceso de Gestión de Recursos.


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 preocu-pació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 au-toras, quienes forman parte del grupo editor de MoProSoft y EvalProSoft, comparten su experiencia en el proyecto de pruebas controladas de este modelo.

Pruebas Controladas de

MoProSoftExperiencia en la ImplantaciónPor Claudia Alquicira y Angélica Su


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 con-sultorí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

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

Experiencia en la EmpresaPara 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 comprome-ter, por tanto se dio una capacitación introduc-toria. En la mayoría de las empresas participó un alto porcentaje de los involucrados directa-mente en el desarrollo de software, y la parte directiva de la misma.

Planeación del Proyecto de MejoraLa planeación del proyecto se realizó en una reunión con el responsable de Gestión de Procesos para el establecimiento del al-cance del proyecto de mejora en su organi-zació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 pilo-tos 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 direc-tor de la empresa, para obtener su apoyo y compromiso de que lo establecido en éste se llevara a cabo.

Definición de los ProcesosPara definir los procesos, primero se presen-taba el proceso al responsable del mismo, y en caso de existir, al equipo de definición.

El ajuste al proceso estaba a cargo del responsa-ble, y consistió en la integración de las prácticas (actividades, herramientas, procesos, procedi-mientos o metodología) de la organización a los procesos MoProSoft, así como la definición o ajuste de plantillas, que sustentarían los produc-tos establecidos en el modelo.

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

ImplantaciónPara iniciar con la implantación de los proce-sos 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 rea-lizar 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 in-volucrados en los diferentes proyectos.

Experiencia en ConsultoríaComo 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 de-sarrollo de software.• Establecer el camino a seguir utilizando MoProSoft por niveles de capacidad, permi-te a las empresas definir metas alcanzables que los motiva a continuar con la mejora de procesos.• Se verificó que para poder implantar exito-samente 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

CASO DE ESTUDIO


Magnabyte es una de las empresas que participó en el proyecto de prue-bas controladas. Esta es la narración de la gente de Magnabyte involucra-da en el proyecto:

Magnabyte, siendo una empresa “típica” mexica-na, 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 realiza-ron 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 Magna-byte. Posteriormente, se realizó la evaluación inicial mediante entrevistas al personal de la empresa, documentos como encuestas, evi-dencias de procesos y de productos, etc. a los evaluadores. La información obtenida les per-mitió 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 cono-cer los resultados obtenidos y el nivel inicial de madurez de nuestros procesos. Al conocer los resultados nos llevamos una gran sorpresa; de-finitivamente, 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 ni-vel 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.

Para la implantación del proyecto piloto se asignaron tres consultores: un consultor ca-pacitado en MoProSoft y dos consultores en formación, quienes nos apoyaron en la capacitación, planeación, definición e im-plantació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, du-rante 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.

Los avances y beneficios obtenidos, se ob-servaron 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 bue-nas bases de crecimiento.

Evaluación finalYa que finalizó el periodo de implantación, se presentó nuevamente el equipo evaluador. Nos dio una capacitación breve de Eval-prosoft, el método para realizar la evalua-ció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 evalua-ció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.

HerramientasDurante la implantación de MoProSoft, nos apoyamos en algunos productos que Magna-byte comercializa: • QPMX – Administración de procesos• SINA – Control de las actividades adminis-trativas. • Gestar – Administración de flujos de trabajo (Workflow).

Dificultades EncontradasNo todo fue fácil, en un inicio sí tuvimos al-gunos contratiempos y confusiones. Nos en-frentamos a la resistencia al cambio en algunas áreas, pero la adaptación a las nuevas formas de trabajo se dio relativamente rápido. Tam-bién hubo problemas de comunicación y en-tendimiento 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 requerimien-to formal de un cliente.

Siguientes PasosActualmente seguimos trabajando para que toda la organización alcance el nivel 2 y de ahí continuar elevando la madurez de nues-tros procesos, para ofrecer mayor calidad en nuestros servicios. Ah, y claro, también esta-mos 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

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 proyec-to se documentaron las sugerencias de me-jora desde el punto de vista de consultoría.• Se obtuvo una retroalimentación bidirec-cional entre organizaciones y consultoras, por la misma concepción del proyecto. Es decir, se estableció un acuerdo de colabo-ració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 es-fuerzo de mejora basándose en MoProSoft.

Finalmente, es importante mencionar que por ser un proyecto de mejora, algunos elementos presentados en este traba-jo 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.

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

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.

Ediciones de JavaLa plataforma Java está compuesta por tres ediciones distintas:• Java 2 Edición Empresarial (J2EE), para servidores empresariales y es-taciones de trabajo que integran sus operaciones entre clientes, proveedo-res 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ásicosen J2ME¿Cómo puede correr Java en un re-frigerador, en un celular, en un PDA? Para responder a esta pregunta se requiere explicar cuatro elementos importantes: (Ver Fig. 1)

Figura 1. Conceptos en J2ME.

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 len-guaje interpretado que requiere de una

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 carac-terísticas similares). (Ver Fig. 2)

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 dis-positivo. Un perfil puede ser agregado a otro perfil. De ahí que los fabricantes como Nokia provean APIs de programa-ción para sus modelos más recientes.

Al mencionar las siglas CLDC/MIDP nos referimos a la configuración (CLDC) y el perfil (MIDP) para programar aplicacio-nes Midlets en teléfonos celulares.

Existe una natural resistencia a pro-gramar 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.


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

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

Los dispositivos móviles están en todas partes, en par-ticular 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 evolu-ción, es una explosión de dispositivos móviles.

Existen varios lenguajes (tecnologías) para programar te-lé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.

PRÁCTICAS

PROGRAMCIÓN

J2MEDESARROLLO DE APLICACIONES PARA TELÉFONOS CELULARESPor Víctor M. Quijano

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 2 Mb TFD, 65K colores. MIDP 1.0

Ericson 128x160 pixels

V3 Razr Motorola 5.5 Mb TFT, 256K colores. MIDP 2.0, 100 kb

176x220 pixels, tamaño máx de

9 líneas archivo JAR

K700i Sony 41 Mb TFT, 65k colores. MIDP 2.0

Ericson 176x220 pixels,

7 líneas

3320 Nokia - No No

S40 Siemens - No No

PRÁCTICAS

PROGRAMCIÓN

puede decir “yo soy un programador Java de aplicaciones corporativas”, ¿cómo afecta al ciclo de desarrollo Java el uso de configura-ciones y perfiles?

Las configuraciones aceptan archivos Java (.class) y JAR, la diferencia está en el com-pilador 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 ins-taladas en una computadora.

Hola Mundo MidletAhora 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 Win-dows). 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ícu-lo ya estaba disponible la versión 2.3 beta, para los aventureros.

Figura 3. Ktoolbar.

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,

nos pedirá nombre del proyecto y clase prin-cipal 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).

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

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:

Tabla 2. Archivo JAD.

Las configuraciones opcionales son:

Tabla 3. Configuración en WTK.

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

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:

Programar Midlets recuerda mucho a programar Applets, los cuales cayeron en desuso (mejor di-cho, se perdió el gusto de programarlos).

Un MIDlet hereda o extiende la clase javax.microedition.midlet.MIDlet. Los métodos re-queridos 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

4 {

5

6 public HolaMidlet (){}

7 public void startApp(){}

8 public void pauseApp(){}

9 public void destroyApp(boolean

unconditional){}

10 }

El código anterior es un código zombie, ca-mina pero no reacciona. Para corregir esto

Opciones DescripciónMidlet-JAR-Size Tamaño del archivo JAR. El WTK lo pone en automáticoMidlet-JAR-URL Dirección Web donde se descarga el archivoMidlet-Name Nombre de aplicaciónMidlet-Vendor AutorMidlet-VersionMicroEdition- CLDC 1.0 en nuestro casoConfiguration MicroEdition-Profile MIDP 1.0 en nuestro caso

Opciones DescripciónMidlet-Data-Size Cantidad de memoria (mínima) que requiere utilizar la aplicación en el equipoMidlet-Delete- Mensaje que se mostrara cuandoConfirm se intente eliminar la aplicación del equipoMidlet-Description Breve descripciónMidlet-Icon Asociado a la aplicación en formato PNGMidlet-Info-URL Liga de la empresa desarrolladoraMidlet-Install- Liga de notificaciónNotify MicroEdition-Profile MIDP 1.0 en nuestro caso

Carpeta ContenidoBin Archivos JAD y JARClasses *.class de JavaLib Otras clases ya compiladasRes Imágenes y otros datos que se utilizaranSrc *.javaTmplib, Archivos temporalestmpclasses


falta el manejo de eventos, lo cual requie-re implementar la interface CommandLis-tener y esto nos lleva a definir el método CommandAction().

Para hacer esto, agregamos el import corres-pondiente:

import javax.microedition.lcdui.

CommandListener;

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,

Displayable s)

{

if (c == cmdExit) {

destroyApp(false);

notifyDestroyed();

}

}

Para que esto funcione, es necesario impor-tar las clases correspondientes a Command y Displayable.

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.Displaya-

ble;

Así como definir la variable cmdExit, la cual representa al comando para el botón de sa-lida (exit).

private Command cmdExit;

Ahora declaramos un objeto display, que uti-lizaremos como referencia a la pantalla. Pri-mero importamos la clase correspondiente:

import javax.microedition.lcdui.Display;

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

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

display = Display.getDisplay(this);

cmdExit = new Command(“Salir”, Command.

EXIT, 1);

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.

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;

y definimos el objeto

private TextBox tbxMain;

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

tbxMain = new TextBox(“HelloMidlet”, “Hola

Mundo Móvil”, 50, 0);

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

tbxMain.addCommand(cmdExit);

tbxMain.setCommandListener(this);

Después de compilar la aplicación y gene-rar 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 reco-mendación final verifique las versiones de CLDC y MIDP de su teléfono para que pueda correr en su teléfono.

El listado final del código queda de la si-guiente manera:

PRÁCTICAS

PROGRAMCIÓN


1 import javax.microedition.midlet.MIDlet;

2 import javax.microedition.lcdui.

CommandListener;

3 import javax.microedition.lcdui.Display;

4 import javax.microedition.lcdui.Command;

5 import javax.microedition.lcdui.

Displayable;

6 import javax.microedition.lcdui.TextBox;

7

8 public class HolaMidlet extends MIDlet

implements CommandListener {

9

10 private Display display;

11 private Command cmdExit;

12 private TextBox tbxMain;

13

14 // constructor

15 public HolaMidlet () {

16 display = Display.getDisplay(this);

17 cmdExit = new Command(“Exit”,

Command.EXIT, 1);

18 tbxMain = new TextBox( “HelloMidlet”

, “Hola mundo movil”, 50, 0);

19 tbxMain.addCommand(cmdExit);

20 tbxMain.setCommandListener(this);

21 }

22

23 public void startApp() {

24 display.setCurrent(tbxMain);

25 }

26

27 public void pauseApp(){}

28 public void destroyApp(

boolean unconditional){}

29

30

31 public void commandAction(Command c,

Displayable s)

32 {

33 if (c == cmdExit) {

34 destroyApp(false);

35 notifyDestroyed();

36 }

37 }

38 }

PRÁCTICAS

PROGRAMCIÓN

Conclusión¿Por qué usar J2ME? Algunas ventajas re-portadas:• Es un estándar actual de la industria res-paldado por Sun Microsystems.• Puede correr en el escritorio y en disposi-tivos móviles.• Continuas versiones de actualización a través de un comité JCP (Java Community Process).• APIs de desarrollo de terceros para nue-vas características en los equipos de nue-va generación.

Sin embargo, J2ME también puede tener al-gunas 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 implemen-tada en versiones anteriores.

Los Midlets han dejado de ser aplicaciones sólo para juegos, pasando por aplicacio-nes 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 Databasewww.j2mepolish.org/devices-overview.html

Recuerda verificar las versiones MIDP y

CLDC de tu teléfono


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.

ebXMLEL FUTURO DE LA INTEGRACIÓN ENTRE EMPRESAS

Durante más de veinte años, el intercambio electró-nico de datos (EDI) ha permitido a las empresas rea-lizar 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 em-presas chicas no siempre tienen la capacidad de integrarlo con sus sistemas internos. Adicionalmente, se requiere la contra-tación de redes de valor agregado o VANs (Value Added Net-works), 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 Langua-ge), es un conjunto de especificaciones que habilitan a las em-presas para realizar negocios a través del Internet. ebXML viene a convertirse en la evolución de EDI, aprovechando sus venta-jas 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 modela-do de procesos, en vez del modelado de información. En pocas palabras, se ve como la gran promesa de unificación para tran-sacciones 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 especificacio-nes, 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ónCon integración nos referimos a aplicaciones que funcio-nan por separado, pero que comparten información de

forma automática. Existen dos tipos de integración:

• Integración de aplicaciones empre-sariales (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 soft-ware que automatiza las interaccio-nes de los procesos externos entre empresas. Estos procesos constitu-yen 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 inte-gració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 re-presentación del mundo real. Por otro lado, no es posible aprovechar todos los beneficios que implica la transferencia electrónica de información entre empre-sas asociadas, si no se cuenta con una apropiada integración hacia el interior.

El modelo clásico cliente-servidor acos-tumbra 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 em-presa, y muchas veces su ventaja com-petitiva 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.

UMMUN/CEFACT Modelling Methodology (UMM) es un conjunto de reglas y pro-cedimientos 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 de-sarrollar 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 mo-delo 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 soft-ware típicamente conllevan una serie de pasos que se mueven des-de un modelo independiente de la tecnología a una implementación tecnológicamente dependiente.

Por Atanacio Reyes

PRÁCTICAS

ARQUITECTURA

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 ebXMLLa visión de ebXML es crear un mercado global, donde em-presas 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 ac-ceder a tales productos y servicios, determinar cómo realizar el intercambio de información, y entonces convenir los acuer-dos 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 in-formación visualmente (en UML), y que éstos sean interpreta-dos 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 formal-mente 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 requeri-mientos necesarios para la interacción. El CPP contiene informa-ción esencial incluyendo pero no limitado a: datos de contacto, clasificación industrial, transacciones posibles, protocolos posi-bles (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 defi-nan 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 inter-sección entre los CPP en cuestión.

PRÁCTICAS

ARQUITECTURA

• Messaging Service Specification (MS). Define las interfaces necesarias para atender el empaquetado, enruta-miento y transporte de mensajes y las operaciones que deben realizar los obje-tos 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 documen-tos 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 cual-quier formato (ASC X12, HL7, EDIFACT, binarios, etc.), no necesariamente XML.

• Registry/Repository (RR). Provee almacenamiento, búsqueda y recu-peració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 distin-ción entre registro y repositorio, de esta forma es posible implementar repositorios distribuidos accedidos a través de un registro. La implementa-ción más común de un repositorio es mediante una base de datos relacio-nal, 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, servi-cios, información de usuarios y orga-nizaciones, 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), cono-cida también como Object Manager. Formada por métodos necesarios para registrar, clasificar, asociar y re-mover objetos almacenados en el re-positorio.Query Management (QM), conocida también como Object Query Manager. Controla el descubrimiento y recupe-ració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 pro-vee 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 pro-tocolo, y las condiciones de seguri-dad 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 repo-sitorios se recomienda a empresas con giros relacionados, con el fin de que puedan conducir e integrar sus proce-sos externos mediante los cuales se re-lacionan. El registro/repositorio permite a estas empresas agruparse en una co-munidad o asociación.

ConclusiónTal como se mencionó anteriormente, no es obligatorio que la estructura ebXML se adopte en su totalidad. Muchos auto-res y empresas recomiendan implemen-tar primero el transporte de mensajes (MS), y posteriormente implementar las otras especificaciones conforme se va-yan necesitando.

En un artículo próximo hablaremos con mayor detalle sobre la estructu-ració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


Figura 1. Red de actividades de un proyecto con

protecciones por actividad.

La pregunta es: ¿por qué si todos agregan tiem-po de protección, el proyecto inevitablemente se atrasa? Para responder esto, analizemos al-gunos aspectos que afectan las actividades del plan de trabajo:1. El “síndrome del estudiante”. Como los programadores saben que cuentan con un col-chó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 dispo-nible el tiempo que originalmente habían es-timado. 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 pro-tecció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 des-tinado para él. ¿Cuál es el incentivo para un programador que termina su actividad con an-ticipación? ¿más trabajo? Si una actividad se termina antes de lo calendarizado y no existe un incentivo por terminación anticipada, el res-ponsable 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.

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

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

Cadena CríticaEntre las metodologías orientadas al segui-miento 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 in-tervalo más corto de tiempo, donde un evento dependiente es aquel que utiliza como insumo tareas que otro evento produce, o utiliza recur-sos 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 ca-lendario. 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 alimenta-dora, se agrega un “amortiguador” que proteja a toda la cadena. En la figura 2 vemos un ejem-plo de la ubicación de los “amortiguadores” en la secuencia de actividades y podemos apreciar que no cambia la fecha de terminación del pro-yecto, simplemente quitamos la protección indi-vidual de las actividades y la ubicamos al final.

Juan, 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 acti-vidades clasificadas en tres áreas fundamenta-les: 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, ¿es-tamos asegurando el éxito del proyecto?, por supuesto que no. Tener una buena planifica-ció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, debi-do principalmente a la naturaleza intangible e intelectual del producto esperado. Por ello, es obligado tomar en consideración las acti-tudes del ser humano en el desarrollo de una actividad dentro de un plan de trabajo.

Volvamos con nuestro atribulado adminis-trador de proyecto, Juan. Durante la estima-ció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.


PRÁCTICAS

ADMINISTRACIÓN DE PROYECTOS

Por José Martín Olguín

CADENA CRÍTICASEGUIMIENTO Y CONTROL EFICIENTE DE PROYECTOS

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.

www.softwareguru.com.mx

Por José Martín Olguín

CADENA CRÍTICASEGUIMIENTO Y CONTROL EFICIENTE DE PROYECTOS

Figura 2. Red de actividades con amortiguadores.

El control del proyecto se hace monitorean-do el consumo de los “amortiguadores”, con este mecanismo se evita que el equipo de desarrollo tenga que reaccionar a falsas alar-mas 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 fe-cha final de entrega del proyecto.• Las personas participantes estarán concen-tradas en una sola actividad a la vez. Es decir, no es posible participar en varias actividades simultáneamente.• Cada persona tendrá que reportar periódi-camente 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 supervi-sión del consumo de los amortiguadores de tiempo, tomando las acciones pertinentes cuando estos consumos sobrepasen límites establecidos de antemano.

Cadena Crítica en Ambientes Multi-proyectosUna 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

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 com-petencia por los recursos. De esta forma, el reto más importante para CC es calendarizar los recursos compartidos de manera que es-tén enfocados en una tarea al mismo tiempo.

ConclusionesAunque el método de Cadena Crítica implica más aspectos que los aquí presentados, aho-ra Juan ya tiene una mejor manera de organi-zar 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 activi-dad 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 si-multáneas para un recurso.4. Debe pedir reportes periódicos de estima-dos de conclusión de las actividades en curso.5. Si una actividad se retrasa, no debe alar-marse. Los retrasos en una actividad le restan tiempo a los “amortiguadores”, pero las termi-naciones anticipadas le suman tiempo. De ma-nera 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 adop-ción de CC en las organizaciones es el cambio de cultura que implica trabajar con este con-cepto, particularmente en la eliminación del “colchón” de protección, mecanismo al que las personas están acostumbradas.

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 Soft-ware Projects”, IEEE Software, May-June 1999.

PRÁCTICAS


Mariana Pérez-Vargas, es Directora General de Avantare y Lead Assessor Certificada 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.

Mucho 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 organiza-ciones 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 madu-rez 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 orga-nizaciones 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áticamen-te. La respuesta es no. Un nivel de madurez y capacidad alcanzado por una organización o área interna, no se pier-de a causa del nuevo modelo. El resultado de una evalua-ción para determinar un nivel de madurez o capacidad, es

como una foto, que refleja en ese mo-mento 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 institucionaliza-ción de las prácticas.

¿Por qué surgió CMMI?Este modelo surge como una alterna-tiva para dar solución a los siguientes cuestionamientos: • Productos más complejos que re-quieren 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 servi-cio 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, Sys-tems Security CMM, IPC CMM, etc.), los cuales tenían diferentes estructuras, formatos, términos y formas distintas de medir la madurez. Esto causaba confu-sión, especialmente cuando una orga-nización estaba utilizando más de un modelo de referencia y era difícil de in-

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

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

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

PROCESOS

Transición deSW-CMM a CMMI

“En la carrera por la calidad no hay línea de meta.”Por Mariana Pérez-Vargas

Las DisciplinasEl 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 disci-plinas como el desarrollo integrado de procesos y productos (IPPD – Integrated Process and Pro-duct Development) y la de atención a proveedo-res (SS – Supplier Sourcing). La estructura del modelo permite la incorporación de otras disci-plinas en el futuro.• SE cubre el desarrollo completo de un sis-tema que puede o no incluir software. Un ejemplo de esto son los sistemas de opera-ción que manejan instituciones financieras, aseguradoras y de aviación.• SW cubre el desarrollo, operación y manteni-miento de software.• IPPD considera la colaboración entre los di-ferentes 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 celu-lar donde se integran muchas áreas como hard-ware, software, diseño y mercadotecnia.• SS cubre la adquisición de productos suminis-trados 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 es-pecíficas en el modelo y deben ser considera-das 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 esca-lonada. Y por si fuera poco, había otros que utilizaban una representación híbrida, como el IPD CMM. Esto generó una disyun-tiva 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 repre-sentación del modelo, la escalonada y la continua para que cada organización de-

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 espe-cífica de implantación. Su estructura es familiar para aquellas organizaciones que están hacien-do 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 proce-sos... Su estructura es familiar para aquellos que están haciendo la transición de ingenie-ría de sistemas.

SW-CMM vs. CMMI SE/SW El modelo CMMI SE/SW en su representa-ció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 cam-bios, 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, ser-vicios (de alto nivel), así como definir los canales de comunicación formales para obtener el en-tendimiento de los requerimientos. Establecer un programa de métricas, fortaleciendo las me-diciones 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 proce-sos para administrar los acuerdos con provee-dores, 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 posi-bles alternativas, con la finalidad de reducir los riesgos en la toma de decisiones. Expan-dir 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 clari-dad y organización de las áreas de proceso. Las organizaciones deberán dar mayor énfa-sis en la administración cuantitativa, implan-tando las técnicas cuantitativas de medición que utiliza la organización. Reforzar la capa-citació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 recolec-ció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.



Hoy en día encontramos software en automóviles, armamento militar, ce-lulares, refrigeradores, etc., cada vez

dependemos más de él. Sin embargo, éste no es 100% confiable y libre de errores. Todos co-nocemos 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 pro-ducir y los segundos en consumir productos de software confiables. El concepto de cali-dad 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 nego-cios se han orientado al cliente y además la globalización ha propiciado una fuerte com-petencia 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 sis-tema o aplicación, con el objetivo de mejorar el proceso de desarrollo. Para finalizar presenta-mos 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 sur-ge 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 Homo-gé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 me-didas 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 soft-ware es permitir que éste funcione con el me-nor 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 res-puesta única, todo depende del proyecto, de la organización, del ambiente de operación y de los desarrolladores, por mencionar algu-nos factores. Sabemos que en la actualidad

es casi imposible desarrollar software com-pletamente libre de errores, por lo que es cla-ro que al medir la confiabilidad del software, los resultados son una aproximación a la rea-lidad, 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, con-tinuar 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, detec-ción y corrección de defectos en las diferentes fases de desarrollo. Una vez que tenemos este modelo, si contamos con la información ade-cuada, podemos estimar y predecir la confia-bilidad del software. Este modelo puede ser de gran utilidad en la toma de decisiones relacio-nada con la liberación del producto, ya que per-mite 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 va-rios 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 proce-dimientos e ideas que provienen de un campo más maduro, la confiabilidad de manufactura. Esto no significa que ambos campos sean igua-les y deban ser tratados de la misma forma, las ideas generales son comunes en ambos cam-pos, pero el patrón de confiabilidad se desen-vuelve de forma diferente a través del tiempo y la génesis de las fallas es muy diferente en

Por Cuauhtémoc Lemus, Enrique Villa y Joaquín Arellano

CONFIABILIDAD DEL SOFTWAREDESARROLLANDO PRODUCTOS CONFIABLES

PRÁCTICAS

ASEGURAMIENTO DE CALIDAD

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 Confiabilidad 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 sis-temas 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.

CONFIABILIDAD DEL SOFTWARE ambos dominios. En manufactura las fallas es-tá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 dife-rencia se expresa gráficamente en las siguien-tes 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 ma-nufactura, 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 laten-tes, 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 fa-llas 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 com-ponentes 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. Ini-cialmente la tasa de errores es alta y con el tiem-po va disminuyendo, debido a que el software se encuentra en su etapa de desarrollo. Esto es, cuando el software es liberado y puesto en ma-nos 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.

Métricas de ConfiabilidadCuando 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 rela-cionadas con la confiabilidad, como por ejem-plo, 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 es-timadas 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 confiabi-lidad, nos referimos a la determinación actual de la confiabilidad, haciendo un análisis esta-dí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, po-demos evaluar el ajuste del modelo de confiabi-lidad a los datos de fallas del software.

La predicción de confiabilidad del software, es la determinación a futuro de esta métrica,

basada en información del software. Pode-mos 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 con-fiabilidad y posteriormente hacer predicciones, estimando las métricas de interés en diferentes tiempos futuros. En cambio, cuando no conta-mos con datos de falla del software, debido a que nos encontramos en la etapa de diseño o desarrollo, utilizamos algunas métricas y me-didas 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 predic-ción temprana 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 in-serción, detección y corrección de defectos.

La aplicación de modelos de confiabilidad de software en los diferentes proyectos de una organización, además de servir para pronos-ticar la confiabilidad en cualquier tiempo fu-turo, 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 de-sarrolladores de acuerdo a la tasa de defectos que introducen en el software. Esta calificación puede servir para determinar programas de ca-pacitación o para la distribución de estímulos.

Confiabilidad de SW en MéxicoEl 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 Confiabilidad 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.


PRÁCTICAS



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 pro-ductoras 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 con-fiabilidad de software, debido a que una buena investigación necesita enfrentarse a problemas reales con un nivel de compleji-dad importante. Esta complejidad requiere de herramientas provenientes de la probabi-lidad y la estadística, que tienen un nivel de sofisticación notable, debido a que los mo-delos requeridos para analizar los patrones de falla en un determinado software, deben considerar el carácter aleatorio de la interac-ción desarrolladores-software-usuarios.

Las empresas medianas de software en México, utilizan algunas métricas para me-dir la calidad de software, pero no modelan los procesos de inserción, detección y co-rrección de defectos. Las grandes empresas trasnacionales, tienen sus centros de inves-tigació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, ubica-dos en el extranjero.

Para desarrollar investigación en confia-bilidad de software se requiere de la con-junció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 Investi-gación en Matemáticas (CIMAT), por lo que en tiempos recientes se ha formado el Gru-po 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 CI-MAT. 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 in-genierí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 ha-cer desarrollos orientados a coadyuvar en la solución de problemas.

ConclusiónActualmente 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 confia-bilidad de software predictivo, con lo cual sería posible optimizar los procesos. El es-tablecimiento de un sistema adecuado de recopilación de datos, requiere de un cam-bio 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 pro-duce es vital. Por ello, no solo es reco-mendable adoptar modelos y procesos como TSP/PSP, CMM, y MoProSoft, sino también reforzarlos con herramientas de calidad como el enfoque a procesos, mejo-ra continua, control estadístico, etc., que en conjunto permitirían lograr que se de-sarrollara software de calidad y por ende, más confiable.

Referencias[1] Jelinski, Z., and Moranda, P.B.: “Software Reliability Research,” Proceedings of the Sta-tistical Methods for the Evaluation of Computer System Per formance, Academic Press, 1972, pp. 465-484.[2] Goel, A.L., and Okumoto, K., “Time-Depen-dent Error -Detection Rate Model for Software and Other Performance Measures,” IEEE Tran-sactions on Reliability, vol. R-28, no. 3, August 1979, pp. 206-211.[3] Yi-Ping Chang, “An Alternative reliability eva-luation 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 Sys-tems and Software Engineering and Technology, March 24 - 27, 1999.[5] Pan, Jiantao, Software Reliability, Carnegie Mellon University, 18-849b Dependable Em-bedded 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.

En México, los centros de investigación y algunas empresas tendrán un papel fundamental en el

desarrollo de la confiabilidad del software.


UML

Especificaciones de Casos de UsoLO QUE BIEN COMIENZA, BIEN ACABAPor Sergio Orozco

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

Si 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 MalentendidosComo es bien sabido, la mayoría de las fa-llas 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 bue-na 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á to-talmente consciente de qué es lo que quiere o necesita. Ahí es donde el analista entra al rescate, pues debe facilitarle al usuario ex-presar sus necesidades para validarlas pos-teriormente mediante mecanismos eficientes de comunicación que ambos entiendan. Un ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.

Aclarando el PanoramaPartiendo de la premisa de que ya se iden-tificaron los actores y casos de uso apropia-dos del sistema (ver número anterior: Casos de Uso y el Valor del Sistema) lo que corres-ponde es detallar los pasos necesarios para cumplir con dicho caso de uso. Para especi-ficar 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 secun-dario 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 (consul-ta 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 se-pamos de la funcionalidad del sistema, más precisas serán las estimaciones de nuestro plan de trabajo.4. Escenarios.- Un caso de uso muestra dife-rentes escenarios posibles y no una sola for-ma 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écni-cos 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 cum-plirá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 tra-ta el caso de uso solicitado por su cliente, y después escribimos eso mismo en las espe-cificaciones, generalmente logramos así un documento más claro que cuando lo escri-ben directamente sin platicarlo. La experien-cia 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 regis-tra 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 recibi-do 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


Generalmente se recomiendan varios ele-mentos adicionales para documentar los casos de uso. Sin embargo, puedo asegu-rarte que la esencia es lo mencionado an-teriormente. Algunos de esos elementos extra con los que puedes complementar tu plantilla para documentar tus especifi-caciones de casos de uso son:

• Propósito. Si comienzas por este punto se te facilitará definir los pasos más rele-vantes para ejecutar el caso de uso.• Precondiciones. Son las condiciones que se deben de cumplir en el sistema an-tes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualiza-do, debe estar en conexión con otro siste-ma, 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, asocia-do al caso de uso especificado.• Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una re-lación de <<extend>>.

En los cursos prácticos de UML que im-partimos, una de las inquietudes que nos expresan más frecuentemente los analis-tas es el hecho de que el cliente no está dispuesto a pagar el esfuerzo requerido para realizar la “documentación” que im-plica especificar los casos de uso. El error,

en primer lugar, es que no lo deberíamos de ver como “la documentación” del sis-tema, sino como una herramienta para esclarecer lo que quiere que le construya-mos. Si no se especifica claramente qué es lo que quiere/desea/necesita el clien-te 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 “documenta-ció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 pro-yecto exitoso. Así que no nos debe de sor-prender que si entra basura, con bastante probabilidad, saldrá basura.

ObtenciónConsiste en averiguar y capturar las funcionalidades que deberá proveer el sistema de información a sus usua-rios. Para obtener los requerimientos, el ingeniero de requerimientos inte-ractú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ónUna vez recabados los datos, el inge-niero de requerimientos le dará forma y orden, clasificará cada uno de los requerimientos, resolverá conflictos encontrados en la información y opcio-nalmente modelará los procesos para poder tener un mejor entendimiento del problema.

EspecificaciónEsta es la parte más importante del pro-ceso de requerimientos. Aquí es donde se documenta la información basándo-se 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 ge-nera en este subproceso es la especifi-cación de requerimientos de software, o SRS (Software Requirements Specifica-tion), documento muy conocido dentro de la industria de software, ya que no se puede concebir una buena documenta-ción de sistemas sino existe un SRS.

ValidaciónLa 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 inten-ta 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 proto-tipo ayuda a verificar que se han en-tendido 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 prototi-po 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 ConsideracionesEs importante recordar que la inge-niería de requerimientos es un proce-so continuo que se lleva a cabo a lo largo de todo un proyecto, y no sim-plemente 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

Hasta hace pocos años no sabía de la impor-tancia 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 in-correctos 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 posterio-res 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.

Cuando realicé mis estudios universitarios, recuerdo que den-tro 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 Inge-niería de Software, y debe ser tomado en cuenta por las insti-tuciones 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, es-pecificación y validación de requerimientos de software. Analicemos cada uno de estos subprocesos:

“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


FUN

DA

ME

NTO

S

Ingeniería de RequerimientosUna Especificación NecesariaPor Jorge Becerril

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

CO

LUM

NACaracterización de la Prueba de Software

Clasificación y Técnicas

En 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 en-contrarse mayor profundidad.

Composición Interna del ComponenteSe 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 funcionali-dad”): centradas en verificar si los requerimientos son satisfechos. Las pruebas de volumen y de stress (ren-dimiento con grandes cantidades de datos, y con bloques de datos por uni-dad de tiempo, respectivamente), son casos especiales de este tipo de prue-ba; 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 especifica-dos, los algoritmos sean adecuados, y la arquitectura sea apropiada. Técnicas comunes son el análisis de algoritmos, la cobertura de decisiones, las revisio-nes entre pares y las recorridas.

Granularidad del ComponenteSe 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 organi-zació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 muta-ción. Suelen ser ejecutadas por el equi-po de prueba.

• Pruebas de sistema: se verifica el sistema como un todo, aplicando pruebas de caja negra utilizando perfi-les de usuario, haciendo v.gr. pruebas como configuración, seguridad, con-fiabilidad 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 in-cluya al cliente, usuario(s) y testers.

Es común que en los esfuerzos de desarrollo se aplique un solo subcon-junto de estas técnicas, guardando el orden en que se acaban de describir.

“Dirección de Avance” en la PruebaPara probar el SUT se diseñan casos de prueba; llamamos pruebas progre-sivas 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 apli-cársele nuevamente los casos de prueba, o al menos un subconjunto de ellas, porque puede ocurrir que en realidad no se realicen las correccio-nes necesarias, o que las correccio-nes 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 im-portante y debe realizarse bajo crite-rios bien definidos y en acuerdo con el responsable general del proyecto. Aún cuando en principio se pudie-ran tener cuantos ciclos regresivos se quisiera, en realidad un número pequeño de ellos muestra tenden-cias 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 PruebaDistinguimos dos ambientes:• Pruebas-α (α-testing), llevadas a cabo de manera controlada en un labo-ratorio de pruebas que trata de repro-ducir el ambiente en que corre el SUT.• Pruebas-β, realizadas al SUT en su ambiente real de aplicación.

Es deseable llevar a cabo ambas fa-ses 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 CriteriosOtras características del SUT que lle-gan 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éc-nicas/herramientas de prueba (v.gr. para probar firmware); la segunda puede exigir cierta profundidad en la prueba que facilite alguna certifica-ción (v.gr. en equipos médicos).

La aplicación apropiada de estas téc-nicas constituyen actividades centra-les del proceso de prueba de software; cuales de ellas se apliquen es una de-cisión crucial que depende de las ca-racterísticas de cada proyecto.

- Luis Vinicio León Carrillo

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


PRUEBA DE SOFTWARE

Luis Vinicio León Carrillo es profesor-investigador del Departamento de Electrónica, Sistemas e Informática del ITE-SO, y director general de e-Quallity S.A. de C.V., empresa espe-cializada en prueba de software. Luis Vinicio es doctorando por la Universidad Técnica de Clausthal, Alemania; su trabajo predoctoral giró alre-dedor a la aplicación de los lenguajes formales en la Inge-niería de Software. Es coautor de un marco tecnológico que hoy permite a e-Quallity desarrollar empre-sas de prueba de software. Luis Vinicio es co-fundador y Secretario actual del Capítulo Guadalajara de la AMCIS.

Un elemento importante para hacer realidad estos escenarios que pare-cen 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 cono-cer dichas condiciones, siendo ahí donde entran en juego los sensores.

AplicacionesLos 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 es-candinavos, 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 hume-dad. 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 Califor-nia; 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á desa-rrollando 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


TECNOLOGÍ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 co-tidianas, 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 comu-nicació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.

WSNRedes Inalámbricas de SensoresPor J. Antonio García y Christian P. García

Aplicación agrícola de WSN

que los nodos de las redes no son computadoras, impresoras, dispo-sitivos 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 procesa-dor 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 recur-sos, se espera que estas redes sean capaces de realizar enrutamien-to, 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 sis-temas para este tipo de redes presenta retos muy interesantes.

Programación de las WSNActualmente los desarrolladores tienen que programar casi directamen-te sobre la plataforma de hardware (sensores), pues no existen biblio-tecas, 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 arquitec-turas 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.

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 es-pecí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; es-tas interfaces permiten a cada componente ofrecer servicios a otros com-ponentes 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 com-ponentes ofrecen a través de sus interfaces pueden ser utilizados por cualquier otro conjunto de componentes creados por cualquier progra-mador y así es como se crea una aplicación en TinyOS con nesC.

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 Commu-nications Magazine, Agosto. 2002.

ConclusiónLas redes inalámbricas de sensores no son solamente un tópico de investigación en la academia, pues ya existen productos dis-ponibles 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.

Samsung

SyncMaster 241MPLos 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 pulga-das, 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.


TECNOLOGÍA

Kingston

Data Traveler EliteAunque no es exactamente lo más sobresaliente en cuanto a diseño, este dispositivo de memoria flash no sólo ofrece des-de 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 almace-namiento compacto en la actualidad.

Hewlett-Packard

iPAQ hx4700Una 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, efectiva-mente, en la PDA más poderosa que se puede adquirir.

Hace unos días me encontraba en la sala de es-pera para abordar el avión que me llevaría de vacaciones al norte del país. Como ya acos-

tumbro, 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 apa-gados, envié un mensaje intrascendente para despe-dirme 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 con-sultar mi correo electrónico en mi computadora por-tá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 oca-sió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 infor-mación inmediata y facilitando transacciones comer-ciales. Los bancos envían mensajes al celular cuando hay un movimiento poco usual en las cuentas, en Eu-ropa el envío de publicidad a celulares (con opción de compra inmediata del producto) se está convir-tiendo 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 re-lativa facilidad para el intercambio de multimedios, información y datos entre dispositivos permite su integración aumentando la productividad o desem-peño de los mismos. Si vivíamos en una era de información, ahora la vemos po-tenciada 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 informa-ción. El impacto social aún está por definirse.

No estoy seguro de querer ser tan fácilmente locali-zable por mi jefe en vacaciones.

Recuerdo una época en que mis compañeros de tra-bajo 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 modi-ficar 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 informa-ció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óvi-les (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 es-tudiantiles y programas de capacitación.

Los desarrolladores de software seremos parte en-tonces de esta sobrecarga de información. Es un buen momento para ser desarrollador. Lo que ha-gamos 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

CO

LUM

NA


Conectividad ContinuaLa Sociedad de los Dispositivos Móviles

CÁTEDRA Y MÁS

El Dr. Raúl A. Trejo es profesor investigador del Departamento de Sistemas de Informa-ción en el Tecnológico de Monterrey, Campus Estado de México. Sus áreas de especialidad incluyen Ingeniería de Software, Representa-ción del Conocimiento y Algoritmos Computa-cionales. El Dr. Trejo gusta de participar en proyectos que involu-cren 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 pre-sentado ponencias en conferencias tales como Americas Con-ference on Information Systems, Internacional Joint Conference on Artificial Intelligence y el Internacional Sym-posium 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.

CÁTEDRA Y MÁS

INDEX

Anunciante Páginas SitioAMITI 09 www.amiti.org.mxAMCIS 55 www.amcis.org.mxARTech 17 www.artech-mexico.comAvantare 39 www.avantare.comSEPG LA 07 www.esi.es/SEPGLAe-Quallity 47 www.e-quallity.netGopac 27 www.gopac.com.mxGrupo STI 29 www.gsti.com.mxIBM F4 www.ibm.com/mxIDC F3 www.idc-eventos.comImexsoft 13 www.imexsoft.com.mxItera 11 www.itera.com.mxMGE 53 www.mgeups.comMicrosoft F2-1 www.microsoft.com/mexicoMilestone 45 www.milestone.com.mxRoca Sistemas 31 www.rocasistemas.com.mxSsistemas 25 www.ssistemas.comVision Consulting 35 www.visionconsulting.com.mxVision Training 35 www.visiontraining.com.mx

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

DIRECTORIO



CA

RR

ER

A

Certificación de HabilidadesCinco Pasos Hacia el Éxito

1. Escoger un Plan de CarreraEscoger un plan de carrera no es algo tan complicado como parece. Por un lado, ex-plora tus intereses y habilidades, y pien-sa qué temas son los que más te atraen. Por otro lado, investiga las tendencias tecnológicas con mayor proyección. Al ba-lancear lo que te interesa con lo que las empresas buscan, obtendrás más y mejo-res oportunidades de crecimiento.

Algunas de las preguntas que te debes hacer son: ¿qué logros me han dado mayor satis-facción en mi carrera? ¿En qué áreas necesi-to desarrollarme más? ¿Qué pretendo lograr en los siguientes años? El objetivo de este análisis es identificar una carrera que coin-cida 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 profesio-nistas y colegas que pueden compartir su experiencia y opinión.

Una vez que decides una carrera y te com-prometes con ella, el resto del proceso de preparación es sencillo.

2. Selecciona Material de AprendizajeExiste 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.

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 desarro-llarte, 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 se-guimiento a tu entrenamiento y mantenerte motivado. Algunos expertos recomiendan planearse para terminar de estudiar cualquier material nuevo con cuatro días de anticipa-ció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 MaestroUna vez que has terminado con el apren-dizaje, estás listo para tomar exámenes de práctica.

Mientras practicas, acostúmbrate a no per-derte en las preguntas difíciles o enredadas. Si sientes que estás perdiendo mucho tiem-po en alguna, sáltatela. Es preferible saltar-se 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áme-nes de práctica. Esto te acostumbrará a pen-sar de manera rápida y eficiente, además de simular la experiencia del examen real.

4. Preparación para el Día del ExamenLa ansiedad previa al examen es bastante co-mú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 an-siedad puede interferir con tu habilidad para enfocarte y contestar correctamente.

Una buena herramienta para reducir la an-siedad, es imaginar lo que sucederá el día del examen. Haz una lista de todo lo que necesitarás. Prepara los materiales e iden-tificación. Planéate para llegar 15 minutos antes de tu examen.

A algunas personas les ayuda realizar ejerci-cios 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 AprenderSi 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 correcta-mente, 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 actua-lizado. Aquellos que se duermen en sus laureles, pronto quedan obsoletos. Contar con la dedicación necesaria para un apren-dizaje continuo no sólo te ayudará a ase-gurar tu trabajo, sino que también te abrirá las puertas a nuevas oportunidades.

La certificación es una excelente oportunidad para desarrollarte profesionalmen-te y lograr una mejor posición. Para maximizar las oportunidades de éxito, te

recomendamos seguir los siguientes cinco pasos:

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

S

epti

emb

re-O

ctub

re20

05A

ño 0

1 N

o. 0

5

Documents

Software Guru CONOCIMIENTO EN PRÁCTICAdesquer.ens.uabc.mx/afi/articulos/SG05_5_sep_oct.pdf · • Conﬁabilidad del Software • ebXML • Administración con Cadena Crítica Software