•

Auditoría de
procesos
• Arquitectura de
software
• Requerimientos
con SysML
Software Guru CONOCIMIENTO EN PRÁCTICA
No.24 • Mayo-Julio 2009 • www.sg.com.mx

[ REPORTAJE ]
Software en
Nuevo León

[ ENTREVISTA ]
Jorge Zavala
Innovación y desarrollo
de negocios globales

México, $65.00

Desarrollo para smartphones

Noticias • Industria • Fundamentos • Carrera • Infraestructura • Gadgets
[ Tutorial ]
Azure
 // CONTENIDO
Editorial
Hace algunos años, en el número 5 de
SG (Septiembre-Octubre 2005) un autor
afirmó que “el software que hará realmente
útiles a los dispositivos móviles todavía no
se ha desarrollado.”
Cuatro años han pasado y ahora estamos
listos para afrontar los retos y salir airo-
sos. Los lenguajes de programación han
madurado, el mercado está en el momen-
to oportuno y el talento mexicano siempre
ha estado presente. Las cartas apuntan a
la gran oportunidad que se presenta para
desarrollar aplicaciones para dispositivos
móviles, especialmente smartphones.
Presentamos una entrevista muy intere-
sante con Jorge Zavala, quien actualmente
dirige la oficina de TechBA en Silicon Valley.
Jorge nos proporciona una interesante vi-
sión de cómo convertir las ideas en gran-
des empresas, y nos comparte su perspec-
tiva sobre la vida en Silicon Valley.
02 MAY-JUL 2009
En esta edición incluimos un reportaje es-
pecial sobre la industria del software en
Nuevo León, presentando un panorama
de lo que se está realizando en el estado,
resultado de la exitosa colaboración entre
academia, empresas y gobierno.
Teniendo esto en cuenta, no es coinciden-
cia que Monterrey vaya a ser la sede de SG
‘09 Conferencia y Expo, que se realizará los
días 27 al 30 de septiembre. Asegúrense de
marcar la fecha en sus planes de proyecto y
prepararse para una experiencia única.
Una excelente noticia es que estamos es-
trenando nuestro nuevo proyecto SG Guía.
Esta es una herramienta a través de la cual
podrán encontrar los productos y servicios
que necesitan para desarrollar software de
alta calidad. Los invitamos a que colabora-
ren y evalúen las herramientas, servicios,
capacitación y aplicaciones contenidos en
SG Guía.
» Equipo Editorial
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Alejandro Escamilla
Arte y Diseño
Dafne Ortega, Oscar Samano
Consejo Editorial
Jorge Valdés - PMI; Luis Cuellar - Softtek;
Francisco Camargo, Luis D. Soto - Microsoft;
Hanna Oktaba - UNAM;
Ralf Eder, Raúl Trejo - ITESM;
Emilio Osorio - Sistemas Humanos;
Luis Vinicio León - e-Quallity.
Colaboradores
Benjamín Ruvalcaba, Miguel Angel Morán,
Misael Monterroca, Germán Dominguez,
Héctor Obregón, Edgar Parada, José Karam,
Carlos Silva, Romeo Márquez, Gunnar Wolf
Yolanda Fernández, Leticia Arevalo,
Jesús Soria, Edith Martínez
Alejandro Bianchi, Gastón Milano,
Charlie Macías, Marco Dorantes,
Consuelo Jiménez, Beatríz Ríos,
Luis Joyanes, Susana Tamayo,
Fernando García.
Ventas
Claudia Perea
Marketing y RP
Paulina Olivares
Circulación y Administración
Edgar Dorantes
Desarrollo Web
Nathanael Gutiérrez
Contacto
info@sg.com.mx
+52 55 5239 5502
SG Software Guru es una publicación trimestral
editada por Brainworx S.A. de C.V., Malinche no. 6,
Col. El Parque, C.P. 53398, Naucalpan, México. Queda
prohibida la reproducción total o parcial del contenido
sin previo aviso por escrito de los editores. Todos
los artículos son responsabilidad de sus propios
autores y no necesariamente reflejan el punto de
vista de la editorial. Reserva de Derechos al Uso
Exclusivo: 04-2004-090212091400-102. Certificado
de licitud de título: 12999. Certificado de licitud de
contenido:10572. ISSN: 1870-0888. Registro Postal:
PP15-5106. Se imprimió en mayo de 2009 en Roma
Color, S.A. de C.V. Distribuido por Sepomex.
www.sg.com.mx
 contenido
may - jul 2009

22 EN PORTADA
Desarrollo de aplicaciones
22

para smartphones

Productos
Lo QUE VIENE 12
RubyMine, CloudBurst, Dryad y Moblin

Herramientas 14
Web testing con Visual Studio

TUTORIAL 16
Aplicaciones en la Nube con Azure

Prácticas
CASO DE ESTUDIO 34
SG Guía
Columnas Compartimos algunas prácticas aplicadas durante
el desarrollo de este proyecto.
Tejiendo Nuestra Red 08 Prueba de Software 52
por Hanna Oktaba por Luis Vinicio León MEJORA DE PROCESOS 36
MoProSoft y la Auditoría de Procesos
Mejora Continua 10 Columna Invitada 54 Guía para la realización de una auditoría.
por Luis Cuellar por Marco Dorantes
ASEGURAMIENTO DE CALIDAD 38
Programar es un Modo 50 Tendencias en Software 56 Medición y Análisis
de Vida por Luis Daniel Soto Recomendaciones para obtener buenas métricas.
por Gunnar Wolf
ARQUITECTURA 40
El Valor de los Ciclos Guiados
En Cada Número por la Arquitectura del Software
Alejandro Bianchi comparte los beneficios de un
Noticias y Eventos 04 INFRAESTRUCTURA 60 ciclo de vida centrado en la arquitectura de software.

INDUSTRIA 06 GADGETS 62 PROGRAMACIÓN 44

Programación Declarativa
FUNDAMENTOS 58 CARRERA 64 Un vistazo a sus características y ventajas.

PM CORNER 46
Revisión de la 4ta edición de la
Guía PMBOK
Presentamos los principales cambios que sufrió

20
Entrevista la guía PMBOK en esta nueva versión.
Jorge Zavala
Innovación y desarrollo UML 48
de negocios globales Los requerimientos al estilo SysML
Aprenderemos los principales elementos para
hacer diagramas al estilo de SYSML.

www.sg.com.mx MAY-JUL 2009 03

 // NOTICIAS

IBM Industry Forum 2009

Con el objetivo de apoyar a las empresas a innovar en su industria
y competir de manera más eficaz para responder a los desafíos
globales, IBM presentó el Industry Forum 2009, del pasado 9 al
11 de marzo en la Ciudad de México.

La estructura de la agenda fue muy buena y brindó contenido

para todo tipo de intereses, ya que el primer día consistió en
conferencias magistrales con enfoque de negocio, mientras que
el segundo día fue dominado por sesiones simultáneas orienta-
das a industrias específicas y el tercer día estuvo dirigido a los
temas técnicos: tecnologías y herramientas, mejores prácticas y
nuevas tendencias.

Tendencias 2009: Modelos de

competitividad con TIC en México
El pasado 18 de marzo, en la Ciudad de México, se realizó con éxi-
to el evento Tendencias 2009, evento que Select ha organizado
de forma consecutiva desde hace 16 años. El evento estuvo enfo-
cado en demostrar la contribución de las TICs y la competitividad
de las organizaciones a través de seis casos de éxito mexicanos,
así como de talleres de benchmarking.

La audiencia estuvo integrada por ejecutivos de alto nivel que cola-

boran tanto en organizaciones públicas y privadas, así como repre-
sentantes de la industria de TIC, todos ellos interesados en identifi-
car las estrategias para competir y aprovechar la tecnología.

MéxicoFIRST
Con la meta de incrementar la cantidad de personas certificadas
en nuestro país, la iniciativa de CANIETI “MéxicoFIRST” presentó
en conjunto con la empresa Sun Microsystems, el proyecto en-
focado en certificar en Java a 12mil estudiantes y profesionistas
de TI. Gracias a que MéxicoFIRST es apoyado por Secretaría de
Economía, quienes deseen certificarse por este medio podrán ob-
tener hasta un 80% de descuento.

Mayor información en www.certificatemexico.com

04 MAY-JUL 2009 www.sg.com.mx

 // EVENTOs

20 y 21 de mayo 2009 22 y 23 de junio 2009

5a. Conferencia Anual de TI 5a. Cumbre de Gobierno y Tecnología
Service Management IDC México
Pink Elephant Hacienda de los Morales, Ciudad de México
Hotel Maria Isabel Sheraton, Ciudad de México Info: www.idclatin.com/events
Info: www.pinkelephant.com Contacto: idc@simrel.com.mx
Contacto: info.mx@pinkelephant.com

10 a 12 de junio 2009 14 y 15 de Julio 2009

XVIII Reunión Nacional de Directores de X Encuentro Iberoamericano de
Escuelas y Facultades de Informática Ciudades Digitales
y Computación Gobierno del Estado de Veracruz
ANIEI World Trade Center, Veracruz.
Tepic, Nayarit Info: www.ciudades.gob.mx
Info: www.aniei.org.mx

14 al 16 de junio 2009 15 y 16 de julio 2009

GITMA - ITESM Congreso Mundial de TI Agile Project Management:
Tecnológico de Monterrey, Campus Santa Fe. Innovation in Action
Info: www.gitma-la.org Cutter Consortium
Contacto: gustavo.pares@itesm.mx Hotel Marriott, Ciudad de México
Info: www.cutter.com.mx
Contacto: agalindo@cutter.com.mx

Global Trends in Software Testing Eventos de software libre

El pasado mes de marzo la empresa e-Quallity invitó a Méxi-
co al reconocido gurú del testing Martin Pol, fundador de Pol-
tec (empresa holandesa de consultoría y certificación) y co-
autor del modelo europeo Test Process Improvement (TPI).
Martin Pol impartió la conferencia “Global Trends in Software
Testing” en Guadalajara, Monterrey y Ciudad de México, en-
focando su plática en la importancia que tiene el uso de las
pruebas de software para incrementar las capacidades de
evitar los riesgos empresariales.
Information Management & BI 2.0
Conference 2009
Con una visión de BI mucho más predictiva, que no se limita
en analizar el pasado, sino que ayuda a entender el futuro,
el pasado mes de febrero IDC presentó exitosamente el In-
formation Management & BI 2.0 Conference, foro diseñado
considerando las principales industrias de crecimiento para el
2009 en el mercado de TI: Gobierno, Servicios y Manufactura,
enfocado en aterrizar los beneficios del Manejo Estratégico de
la Información y el BI para dichos sectores.
El mes de abril fue bastante agitado para los entusiastas
del software libre, ya que en menos de dos semanas se
realizaron cuatro eventos importantes.
Empezamos con el 4to Congreso de Software Libre or-
ganizado por los estudiantes del CCH Naucalpan el 13 y
14 de abril.
Seguimos con la edición 2009 del Consol, que este año
se llevó a cabo en la UAM Azcapotzalco del 14 al 17 de
abril, con la participación de conferencistas como Fer-
nando Romo, Sandino Araico y Palmira Granados.
Posteriormente, del 21 al 23 tuvo lugar el 2do Coloquio
Universitario de Software Libre PUMASOL organizado por
el Laboratorio de Investigación en Software Libre (LIDSoL)
en coordinación con la Facultad de Ingeniería de la UNAM.
Por último, el 25 de abril fue el día del Festival Latino-
americano de Software Libre (FLISOL) 2009, el cual con-
juntó sedes en más de 200 ciudades en 18 países.

www.sg.com.mx MAY-JUL 2009 05

 // INDUSTRIA
Software en Nuevo León
Nuevo León es un estado de gran importancia en términos de la in-
dustria de software en nuestra región. Aquí residen algunas de las
empresas de servicios de TI más grandes, y se ha convertido en una
sede preferida para empresas que ofrecen servicios tipo Nearshore
para el mercado norteamericano. En los últimos años, incluso gran-
des empresas de la India como Infosys, Sasken y Wipro han estable-
cido centros de operación en esta entidad.
Algunos números para comenzar
La industria de software en Nuevo León está compuesta por más de
300 empresas que emplean más de 7 mil personas y generan ingre-
sos por más de 300 millones de dólares anuales.
La distribución de empresas en base a su cantidad de empleados es
la siguiente:
• Micro (1 a 10) 43%
• Pequeña (11 a 50) 31%
• Mediana (50 a 100) 17%
• Grande (más de 100) 9%
En Nuevo León existen 24 empresas certificadas en Moprosoft y 12
en CMMI, es la segunda entidad con más empresas con certificacio-
nes de calidad después del Distrito Federal.
CSOFTMTY
El Consejo de Software de Nuevo León (CSOFTMTY) es el organismo
que coordina lo que se denomina la triple hélice: academia, empre-
sas y gobierno. Esta asociación civil es la responsable de desarrollar
y asegurar el cumplimiento de las estrategias para el fortalecimiento
de la industria de software en esta región.
Para ello, CSOFTMTY se enfoca en siete líneas de acción:
1. Desarrollo de mercado
2. Desarrollo de profesionales de software
3. Desarrollo de empresas y empresarios
4. Desarrollo de infraestructura
5. Sustentabilidad y alto valor agregado
6. Accesibilidad a programas y fondos económicos
Existen 22 miembros de los cuales 12 son empresas, 3 organismos
empresariales (AETI, CANIETI y ORIGO), 5 universidades (ITESM,
TEC Milenio, UANL, UDEM y UR), un representante del Gobierno
de Nuevo León y uno del Instituto de Innovación y Transferencia de
Tecnología (I2T2).
Una característica fundamental de CSOFTMTY es que no es un or-
ganismo gubernamental, sino que es un organismo independien-
te que vincula a la triple hélice: Empresas, Academia y Gobierno
para lograr un propósito común.
06
16 MAY-JUL 2009
Desarrollo de Capital Humano
En términos de capital humano, Nuevo León enfrenta una proble-
mática similar a la de otros estados: la matrícula de estudiantes en
carreras relacionadas con TI ha disminuido en los últimos años, y
por otro lado los recién egresados no poseen las habilidades que
demandan las empresas. Sin embargo, en el caso de Nuevo León
esta situación se agudiza debido a que en los últimos años existió
un alto crecimiento de la industria en la región y se han estable-
cido aquí empresas internacionales, especialmente de India, que
demandan una gran cantidad de personal calificado en TI. Ante
esta situación, el desarrollo de capital humano tiene un lugar pre-
ponderante en la agenda de CSOFTMTY y para ello ha establecido
diversas iniciativas.
Guillermo Safa, director del CSOFTMTY, nos comenta sobre el
factor de éxito más importante en esta iniciativa es el contar con
el Capital Humano en suficiencia y con las capacidades requeri-
das por los mercados internacionales.
Es por esto que esta es la línea estratégica de mayor prioridad dentro
del plan de trabajo de CSOFTMTY; dentro de la cual hay dos iniciativas
concretas en las que se está trabajando:
• Una campaña de promoción entre los jóvenes para que estudien
carreras relacionadas con las TIC’s
• La creación del Instituto de Desarrollo de Talento de TI, único en su
tipo en México
Instituto de Desarrollo de Talento de TI
El Instituto de Desarrollo de Talento de TI (IDETI) tiene como finali-
dad el incrementar, en el corto plazo, el capital intelectual disponible
para la industria de software con certificaciones internacionales. En
veintidós semanas se prepara para el trabajo a recién egresados de
las carreras de TI, actualiza a profesionistas y reconvierte a profe-
sionistas de otras ingenierías para integrarlos a la fuerza laboral de
la industria. Los cursos son tomados en una de las 5 universidades
vinculadas: ITESM, Tec Milenio, Universidad Regiomontana, Univer-
sidad Autónoma de Nuevo León y Universidad de Monterrey.
Los programas de estudio de este Instituto se refieren específicamente
a la certificación en:
• Conceptos de hardware y software de sistemas
• Fundamentos de programación
• Bases de datos
• Metodologías de desarrollo de software
• Análisis de algoritmos
• Conceptos de desarrollo orientado a objetos
• Diseño de interfaces
• Tecnologías Web
• Conceptos Cliente – Servidor
www.sg.com.mx
Solo para TI
“Solo para TI” es una campaña para fomentar que los jóvenes próxi-
mos a entrar a la universidad elijan estudiar carreras relacionadas
a las tecnologías de información. Asimismo, se ha iniciado una es-
trategia pre-universitaria en la que a través de centros de compu-
tación aplicada y la capacitación de maestros de escuelas públicas
de primaria y secundaria se fomente el conocimiento y gusto por las
tecnologías de información y comunicaciones.
Vinculación con universidades
Por su parte, las empresas y universidades también llevan a cabo
actividades de vinculación que resulten en disponibilidad de más ca-
pital humano y con mayor especialización y experiencia:
• Las universidades ofrecen espacio de ubicación a nuevas empre-
sas que llegan a la entidad, lo que les permite acceso directo a
nuevo talento así como a infraestructura temporal para iniciar sus
operaciones (softlanding).
• Las empresas realizan convenios con las universidades para la ab-
sorción directa de talento, así como para la realización de proyectos
con clientes actuales en sus instalaciones. Esta práctica permite a
la empresa reducir sus costos mientras prepara talento con conoci-
mientos de los actuales requerimientos de los usuarios de TIC.
• Las empresas de la India, que en años recientes han realizado
inversiones en la entidad, tienen convenios con las principales uni-
versidades del estado para que estudiantes y profesores visiten sus
centros de capacitación en la India. Durante la visita se identifican
las brechas existentes entre las necesidades actuales de la industria
y el sistema educativo de la entidad y se recibe un entrenamiento
en las capacidades que se necesitan desarrollar dentro del sistema
educativo estatal actual.
Desarrollo de mercado
El mercado local de software y servicios TI en Nuevo León se en-
cuentra bastante consolidado, siendo el segundo mercado local en
importancia en el país. Las grandes empresas usuarias enfrentan
una competencia globalizada y están conscientes de que para des-
tacar en este ámbito es crucial tener un buen aprovechamiento de
las TICs. Por otro lado, se están presentando nuevas oportunidades
de penetración en el mercado gracias a una dinámica de desarrollo
económico que ve al software como coadyuvante en la innovación
de productos y procesos. Para catalizar esto se realizan diferentes
acciones tales como:
• Planes para fomentar la transferencia de tecnología (productos y
servicios de las empresas de TI y de los centros de investigación y
desarrollo) hacia los sectores más estratégicos de la entidad y hacia
los nuevos sectores que están siendo impulsados.
• Promoción entre las empresas más grandes de la entidad para la
contratación de servicios y productos de TI de empresas locales.
• Se está persiguiendo que el gobierno local sea un potencial consu-
www.sg.com.mx
midor de los productos y servicios de las empresas locales. Se pro-
mueve la participación de pequeñas y medianas empresas locales
de TI en proyectos, a través de convenios de integración con grandes
proveedores y a través de la incorporación de la evaluación de pro-
veedores locales en la ley de adquisiciones.
Innovación
Dentro del Consejo, entró en operación un nuevo comité de innovación
en el cual se busca desarrollar la alta especialización del sector basa-
do en innovación y las mejores prácticas mundiales en este concepto.
Este nuevo comité llevará la tarea de homologar en la triple hélice el
concepto de innovación en TI ya que actualmente se tienen diferen-
tes definiciones del concepto. De igual manera, se buscará desarro-
llar innovación en los productos y servicios para obtener márgenes
más grandes en la industria.
Infraestructura
En Nuevo León existe el Parque de Investigación e Innovación Tec-
nológica (PIIT) el cual tiene una superficie total de 70 hectáreas
disponibles para centros de investigación y desarrollo de empresas
en las áreas de salud, mecatrónica, tecnología de información, bio-
tecnología y nanotecnología.
Dentro del PITT esta por inaugurarse el Monterrey IT Cluster, un con-
junto de 42 empresas que compartirán un edificio e infraestructura
desde el inicio de sus operaciones, para posteriormente trabajar en
conjunto e incursionar a mercados internacionales.
MIT Cluster en el PIIT
Más información en:
[www.csoftmty.org]
[www.ti.org.mx]
[www.piit.com.mx]
MAY-JUL 2009 17
07
 // COLUMNA /*TEJIENDO NUESTRA RED*/
Picando piedra: Primera Parte
Recordando a las personas que aportaron su granito de arena para elevar la calidad del software mexicano
La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software,
Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International
Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.
E scribir la columna número 25 para Software Gurú me puso
nostálgica. A lo largo de casi veintiséis años de trabajo en
México he conocido mucha gente, que desde sus espacios, han
impulsado la adopción de buenas prácticas en la industria de
software. Para hacer un pequeño reconocimiento de su labor,
decidí hacer un recuento de sus aportaciones para que las nue-
vas generaciones no piensen que las cosas salen de la nada y
para que se animen a participar.
• 1983, Lupita Ibargüengoitia consigue la primera edición del
libro de Ingeniería de Software de Pressmann y aunque en la
especialización en Computación de la carrera de Matemáticas
de la UNAM no existía materia bajo este nombre, decide impar-
tirla. Tal vez este fue el primer curso de Ingeniería de Software
en México.
• 1983, su servidora llega a México y ofrece el curso sobre Simu-
la 67 en la Maestría en Ciencias de la Computación de la UNAM.
Tal vez fue el primer curso de un lenguaje Orientado a Objetos.
• 1992, Carlos Vizcaíno inicia la publicación de la revista Solu-
ciones Avanzadas, una revista semejante a lo que hoy es SG.
Esta revista fue un excelente medio de transferencia de conoci-
miento y comunicación entre la academia y la industria. Aquí se
publicaron los primeros artículos sobre diversos paradigmas de
lenguajes de programación, OO, UML, modelos, así como están-
dares de procesos y muchos temas más. Desgraciadamente la
revista dejo de existir en 1999.
• 1992, su servidora empezó a dar las primeras conferencias so-
bre ¿Por qué está de moda OO? en los foros de Instituto Mexica-
no de Petróleo, COMDEX y Día Borland, inventando el ejemplo
de ¿cómo se hacen chilaquiles al estilo OO?, para poder llamar
la atención del público.
• 1994, Arnoldo Díaz de la empresa certum comienza a partici-
par en un proyecto de la ISO llamado SPICE (Software Process
Improvement and Capability dEtermination), hoy mejor conocido
como el estándar ISO/IEC 15504 Software Process Assessment.
Llegó a fungir como Project Editor y Miembro del Consejo de Ad-
ministración del proyecto SPICE. La herramienta de Evaluación
de Procesos de Software desarrollada por certum fue denomina-
08 MAY-JUL 2009
da Official SPICE Assessment Instrument. Según mi conocimien-
to fue el primer directivo de la industria y tal vez último hasta la
fecha, quien se involucró personalmente en desarrollar un es-
tándar internacional para poder tener una ventaja competitiva
en el mercado nacional.
• 1997, Gloria Quintanilla y Hanna Oktaba convocan a la primera
reunión del Circulo de Calidad de Software en las instalaciones
de IBM-Technosys. La primer conferencia que se ofrece es de
Francisco López Lira sobre SW-CMM. Asistieron 22 personas, lo
que nos obligó a continuar con reuniones mensuales, una de
ellas en enero de 1998 en Guadalajara con apoyo de la empresa
mexicana Compac. Por la creciente asistencia las reuniones ha-
bían cambiado de sede a un espacio de INEGI (apoyo de Pablo
Noriega y Natalia Volkov) y luego a Infonavit (apoyo de Víctor
Baez). Los conferencistas fueron nuestros colegas académicos o
de la industria y los temas abarcados fueron SW-CMM, PMBoK,
ISO/IEC 15504 (SPICE), Function Points, PSP y muchos más. En-
tre 1998 y 1999 organizamos cuatro seminarios de calidad de
software con el apoyo de AMITI y Soluciones Avanzadas, en los
cuales contamos con la presencia de Watts Humphrey hablando
de TSP, Suz García y Mark Paulk hablando de SW-CMM y William
Hetzel de proceso de pruebas.
• 1997-1998, empezamos a tener las primeras empresas de la
industria de software evaluadas en ISO 9000:1995, tales como
Gedas, Certum, EDS, e IBM-Technosys y la primera en SW-CMM
nivel 2 fue IBM-Technosys.
• 1998, Luis Castro profesor de la UAM-I crea el primer Labora-
torio de Ingeniería de Software en la academia y se convierte
pronto en uno de los primeros instructores PSP.
• 1998, Lupita Ibargüengoitia y Hanna Oktaba abren en la Maestría en
Ciencia e Ingeniería de Software de la UNAM un área de especialización
en ingeniería de software con cursos de Tecnología Orientada a Objetos
y modelos de procesos de Ingeniería de Software (12207, 15504, SW-
CMM, PSP, TSP). En los últimos años estos cursos fueron enriquecidos
con la participación de las instructoras: Ana Briseño (consultora inde-
pendiente), Cecilia Pérez (IBM de México) y Elsa Ramírez (Praxis). Hasta
la fecha Lupita y yo hemos dirigido 48 tesis de maestría relacionadas
con diversos temas de calidad en procesos de software.
www.sg.com.mx
• 1999, Gloria Quintanilla, Francisco López Lira, Lupita Ibargüengoitia
y su servidora fundan la Asociación Mexicana para la Calidad en In-
geniería de Software (AMCIS). A mitad de 1999 el Círculo de Calidad
de Software, tuvo tantos adeptos que se decidió formalizar su exis-
tencia a través de la AMCIS. Durante sus 8 años de existencia varias
personas dedicaron su tiempo para que la asociación funcionara.
Me llegan a la mente los nombres de: Ana Vázquez, Jorge Palacios,
Agustín Gutiérrez, Ana Briseño, Luis Castro, Mariana Pérez-Vargas,
José Manuel Milanés, Carlos Pérez, Maria Julia Orozco, Claudia Al-
quicira, Angélica Sú, Héctor González y muchos más cuyos nombres
se me escapan en este momento. Continuamos con las reuniones
mensuales gracias al Grupo SETI, que nos ofreció el espacio, orga-
nizamos cinco seminarios de calidad de software con invitados ex-
tranjeros y nacionales. Armamos el primer Diplomado de Calidad de
Software que entre 2002 y 2006 fue ofrecido en el Distrito Federal
y en el interior del país. También, editamos cuadernos de calidad
www.sg.com.mx
de software basados en las tesis de maestría. En los últimos años
de la actividad de la AMCIS se crearon sus capítulos en Jalisco (Luis
Vinicio León), Nuevo León (Héctor González), Veracruz (Agustín La-
gunes) y Chihuahua (Joaquín Gálvez).
• 1999, Carlos Montes de Oca llega al CIMAT, Guanajuato, y empieza a
formar el grupo de investigación en Ingeniería de Software y Calidad más
dinámico del país.
Esta es la primera parte de mis recuerdos, que abarca principalmente los
años noventas. Quiero subrayar que este recuento está basado solamen-
te en mis recuerdos personales usando mi memoria de viejita. Invito a
todos mis colegas y a los lectores de SG para que complementen la infor-
mación y que corrijan los datos erróneos.
» Por Hanna Oktaba
MAY-JUL 2009 09
 // COLUMNA
La Cultura de Calidad
Tomemos el reto
Luis R. Cuellar es director de calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality
(ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la
definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.
L a semana pasada terminé un libro llama-
do The Culture Code (El Código de la Cultu-
ra). El libro está enfocado principalmente en
el área de mercadeo y desarrollo de nuevos
productos. Expone el hecho de que para ha-
cer un buen trabajo no es suficiente hacer
entrevistas enfocadas para averiguar los
gustos específicos de un grupo de personas,
pues el entrevistado al tratar de explicar se
ve rodeado de prejuicios e ideas sociales
que se interponen en su definición. Si por
ejemplo preguntamos ¿qué quieres ver en un
automóvil? las respuestas se enfocan en su
velocidad, bajo consumo de gasolina, poco
mantenimiento y demás elementos que defi-
nen a los automóviles actuales. Pero, si pre-
guntamos más a nivel subconsciente a través
de dinámicas de roles, manejo de recuerdos
y demás, las respuestas son totalmente dife-
rentes. Un ejemplo de dinámica sería el aden-
trarse a preguntar tus primeros recuerdos de
un automóvil y las emociones que estos re-
cuerdos te traen, al hacer esto se descubre
que en realidad lo que buscamos de un auto
es la libertad e identidad que nos proporcio-
na, cómo el automóvil nos hace únicos.
El libro da un compendio de lo que el autor ha
encontrado en sus estudios y resume esta in-
formación tratando de encontrar una palabra
que define en la mente de los americanos si-
tuaciones como: sexo, trabajo, salud, etc. Lo
que se me hizo realmente fascinante es que
entre sus estudios se encuentran las defini-
ciones de términos como “calidad” y “cero
defectos” y cómo se compara con la calidad
en la cultura japonesa. De acuerdo al autor los
norteamericanos ligan la palabra calidad con
el hecho de que un producto haga lo que fue
diseñado para hacer sin problemas. En otras
palabras, en norteamérica calidad significa:
“¡FUNCIONA!”. Esto contrasta con la cultura
japonesa en donde la calidad es mucho más.
En esta cultura la calidad está ligada con el he-
cho de que el producto funcione, pero adicio-
nalmente tiene que ver con la pureza y eficien-
10 MAY-JUL 2009
/*MEJORA CONTINUA*/
cia del diseño y cómo lograr, en grupo, cero
defectos. Yo creo que esto se ve claramente
ejemplificado con los problemas que el día de
hoy enfrenta la industria automotriz america-
na. En Detroit la preocupación siempre ha sido
entregar automóviles que funcionen, desde
los tiempos de Henry Ford y su famosa frase
“Te lo podemos dar de cualquier color siem-
pre y cuando sea negro”. El enfoque siempre
ha sido una máquina que te lleve de un lado
a otro. Al mismo tiempo la industria automo-
triz japonesa está en pleno auge liderado por
Toyota. Los japoneses no sólo se preocupan
porque el automovil funcione, sino cómo per-
feccionar todo proceso que involucre al auto.
Hace poco escuché una historia de como la
persona encargada de diseñar la Sienna se
pasó viajando por minivan en Estados Unidos
durante un año para identificar qué debería
y qué no debería contener la camioneta. Es
interesante como nunca se me hubiera ocurri-
do decir que lo que quería de mi auto es una
buena área de mantenimiento y servicio que
me entregue el coche cuando se me dijo y me
costara la tercera parte. Nunca pensé que fue-
ra posible. Ahora después de dos años con mi
Toyota es lo mínimo que espero.
¿Y esto a mí qué?
Bueno, ¿por qué es importante hablar de esto
ahora? Yo creo que este pasaje tiene muchos
puntos de valor para el área de cambio de
una organización. Si suponemos que por ser
la nuestra una cultura occidental hay alguna
posibilidad de parentesco en el ámbito de ca-
lidad con la cultura japonesa, analicemos los
siguientes puntos:
1) El trabajo de un área de cambio es 30%
crear y 70% vender. Por lo que para un vende-
dor esta es información muy importante. Un
punto que no mencioné es que el americano
valora mucho el movimiento, por lo que no
puede asimilar la idea de la perfección, sólo
Dios es perfecto. Ser perfecto implica ya no
moverse, y solamente lo muerto no se mue-
ve, cero defectos implica ser perfecto. Así en
las culturas occidentales no podemos hablar
de cero defectos sino de mejora continua. No
podemos aspirar a ser perfectos, pero sí a
mejorar continuamente.
2) Si el occidental valora que las cosas fun-
cionen entonces existe un gran valor en las
áreas de soporte y de servicio. Si se descom-
pone mi coche lo que quiero es que lo repa-
ren inmediatamente aunque no tenga ningún
plan de salir en él. Si mi programa de soft-
ware falla no hay nada más importante que
el hecho de que funcione nuevamente. Estas
son áreas que normalmente relegamos pero
deberían ser parte de los procesos básicos
de nuestra compañía.
3) Aunque para el occidental la calidad se
ve en el hecho de que algo funcione correc-
tamente, esto lo podríamos ver como un
algo que simplifica nuestro trabajo pero es
un arma de dos filos, ya que esto se vuelve
una característica dada en el producto. Si de
veras quiero maravillar a mi cliente requiero
que mi diseño me haga impresionante.
4) La mejora continua requiere de un trabajo
arduo que toma tiempo, constancia y discipli-
na, pero estas características son tan raras en
una organización que podemos contar con el
hecho que de ese trabajo nos diferencia de
nuestros competidores, muchos hablan de
calidad pero no todos tienen el temperamen-
to para lograrlo.
Es interesante entender estos rasgos culturales
para así vender mejor nuestras ideas, y hacer de
nuestras organizaciones la fuerza competidora
que logrará en forma consistente los resultados
que nuestros clientes están buscando.
Tomemos el reto, es hora de crear nuestra
propia cultura de calidad.
» Por Luis Cuellar
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009 11
 // PRODUCTOS /* LO QUE VIENE*/
RubyMine
Por fin un IDE para Ruby
Como evidencia de la popularidad que está cobrando el len-
guaje Ruby, la empresa JetBrains lanzó RubyMine 1.0, un am-
biente de desarrollo para Ruby y Rails.
RubyMine mantiene el alto estándar de calidad de los productos
de Jetbrains. Entre sus características destacan:
• Editor inteligente que analiza el código e infiere los tipo de
datos conforme escribes.
• Capacidades integradas para aplicar el framework Rails.
• Pruebas unitarias con TestUnit y Rspec.
Más información en: www.jetbrains.com/ruby
IBM WebSphere CloudBurst Appliance
Habilitación de nubes privadas
IBM dio a conocer su estrategia de cómputo en la nube, haciendo
ver que su estrategia no está orientada a la nube pública (como
Amazon o Google), sino a nubes privadas para corporativos. Las nu-
bes privadas consisten en proveer recursos de cómputo y datos vir-
tualizados para ambientes corporativos controlados por el personal
de TI de la organización.
Como parte de esta estrategia, IBM lanzó WebSphere CloudBurst
Appliance, un hardware appliance que integra imágenes virtualiza-
das de aplicaciones sobre servidores xSeries. Cuando los clientes
están listos, las aplicaciones se habilitan en las nubes privadas para
que puedan atender peticiones bajo demanda.
Con CloudBurst, los equipos de desarrollo pueden tener a su entera
disposición los recursos de cómputo del appliance durante el ciclo
de desarrollo, y una vez que todo esté listo y probado se configura
para que los recursos formen parte de la nube privada, administra-
dos por el departamento de TI de la organización.
CloudBurst se integra con el nuevo Rational Automation Framework
for WebSphere para automáticamente optimizar la configuración y
habilitación de aplicaciones. La administración de recursos también
se facilita significativamente por medio de la integración con el Tivo-
li Service Automation Manager.
12 MAY-JUL 2009
Moblin
Linux atómico
Moblin es una edición de Linux optimizada para eje-
cutarse en sistemas basados en la tecnología Atom
de Intel. La visión es proveer una plataforma comple-
ta para aplicaciones enriquecidas que aprovechen las
capacidades de dispositivos tales como NetBooks,
MIDs (mobile internet devices), sistemas de informa-
ción/entretenimiento para vehículos, y otros disposi-
tivos embebidos.
El proyecto se encuentra en etapas tempranas y to-
davía no está listo para producción, pero puede ser
una opción atractiva para quienes estén conside-
rando iniciarse en el desarrollo de aplicaciones para
este segmento.
Más información en moblin.org
Dryad y DryadLINQ
Procesamiento de datos en cluster
Dryad y DryadLINQ son dos proyectos de Microsoft Re-
search orientados a facilitar el procesamiento de gran-
des cantidades de datos en clusters de alto desempeño
(high performance clusters).
El primer elemento, Dryad, es una infraestructura que
habilita programas secuenciales y los optimiza para
que puedan ser ejecutados de forma paralela en clus-
ters distribuidos.
Por su parte, DryadLINQ es un compilador que traduce
programas LINQ a instrucciones de cómputo distribuido
que se pueden ejecutar en un cluster. Para lograr esto,
DryadLINQ particiona de forma distribuida los objetos
de datos de LINQ y convierte las sentencias de LINQ y
métodos de C# en tareas distribuidas de Dryad.
DryadLINQ soporta todas las librerías de .Net y se inte-
gra con Visual Studio para facilitar el desarrollo.
Más información en:
research.microsoft.com/en-us/projects/dryad
research.microsoft.com/en-us/projects/dryadlinq
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009
 // PRODUCTOS /*HERRAMIENTAS*/

Web Testing Utilizando

Visual Studio Team Edition for Software Testers
Creando Web Tests de manera rápida, sencilla y eficiente
Por Benjamín Ruvalcaba

Con la llegada de Visual Studio 2005 Team System, Microsoft intentó

crear un ambiente integrado de desarrollo de software en el cual todas
las actividades del ciclo pudieran tomar lugar. Para satisfacer las necesi-
dades de pruebas del desarrollo de software, Microsoft creó Visual Stu-
dio 2005 Team Edition for Software Testers. Desde aquel lanzamiento,
Microsoft ha puesto en el mercado la versión 2008 de su Team System
suite. Además, existen planes para lanzar la versión 2010 en un futuro
cercano. Esta versión tendrá un énfasis en las actividades e integración
de testing. A diferencia de la mayoría de los productos comerciales, el
objetivo de Test Edition no es la captura de las actividades del teclado o
mouse. La herramienta se enfoca en la captura de las interacciones http
y https entre el cliente y los servidores web. Este enfoque alivia en algo
la frustración que viene con el uso de las herramientas basadas en la
grabación de eventos en la interface gráfica del usuario.

Este artículo proporciona información acerca de conceptos básicos de la

herramienta. El objetivo es dar a los lectores una idea de cómo implemen-
tar la herramienta en poco tiempo y sin los dolores de cabeza comúnmen-
te asociados con el comienzo de la automatización de pruebas.
Creando web tests
Ya que los web test solamente están disponibles en Proyectos Test,
el primer paso hacia la creación de un web test es la creación del
proyecto. Nótese que el tipo de proyecto Test solo existe como com-
ponente del Test Edition de Team System. Puedes agregar el proyec-
to a una solución existente o crear una nueva. Selecciona New >
Project desde el menú File para aparecer el dialogo de New Project.
Selecciona el tipo de proyecto Test, su nombre, .Net Framework que
deseas, y la solución que de deseas utilizar.
Captura1. Creación de nuevo proyecto
Mientras estoy grabando actividad, entro a mi cuenta en el sitio utilizan-
do el link ‘Actualizar Datos’ y reviso información personal. Para finalizar
la grabación oprimo el botón Stop en los controles correspondientes. Al
hacer esto, la herramienta comienza la detección automática de pará-
metros dinámicos. Los parámetros dinámicos son aquellos que se utili-
zan de manera subsecuente al primer uso en la grabación. Una vez iden-
tificados los parámetros dinámicos, el sistema ofrece la oportunidad de
promoverlos para que sean utilizados en corridas posteriores.

Una vez creado el proyecto, debes agregar el web test. Para agregar el
web test puedes oprimir el ícono de New Test o seleccionar New Test
desde el menú de Test. Los diferentes tipos de prueba aparecen en el
dialogo de Add New Test. Los tipos de pruebas que existen incluye: Ge-
neric, Web, Load, Manual, Ordered, y Unit. Selecciona Web Test y captu-
ra el nombre para la prueba y el proyecto que vas a comenzar. Una vez
que hayas presionado OK aparecerá una sesión en blanco de Internet
Explorer lista para iniciar la grabación de actividad del navegador. Los
controles de grabación te permiten comenzar, detener, parar, comentar
o borrar la grabación. Estoy utilizando www.sg.com.mx como dirección
para este ejemplo. Nótese que en cuanto comienza la actividad http se
empieza a grabar. Esto se puede ver en el árbol jerárquico de las requi-
siciones http que aparece bajo los controles de grabación. Captura 2. Despliegue de la prueba y el árbol

Benjamín Ruvalcaba Alonso tiene más de 18 años de experiencia en proyectos de informática. Ha trabajado en Microsoft, GE y otras empresas públicas y
privadas. Ha dedicado los últimos seis años al testing de diversas aplicaciones web.

14 MAY-JUL 2009 www.sg.com.mx

Al completar el paso anterior, el sistema despliega la prueba y el
árbol de llamadas http(s). Este es el resultado de la grabación con
los parámetros utilizados para mi acceso al sitio. Advertencia: La
herramienta no utiliza encriptado. Por lo tanto, todo el tráfico es
visible. Yo oculte mi clave para este ejercicio.
Con la integración de Team Foundation Server, podrías tomar los
resultados y publicarlos para tener control de todas las pruebas
ejecutadas. También es posible la creación de bugs mediante la
utilización de estos resultados.

Como buena práctica, corre el web test para asegurarte que fun-
ciona adecuadamente. Al terminar la prueba, el sistema te desple-
gará un panel de resultados. Para verificar las razones de fallas
puedes oprimir el link de ‘Test run completed’. Esto mostrará una
lista detallada de la corrida de la prueba. Procedamos a agregar
validaciones propias.

Agregando validaciones propias

La herramienta agrega muchas validaciones propias. Asegura que
la página se muestre, verifica que las redirecciones http que ocu-
rrieron durante la grabación sean válidas al momento de ejecu-
ción, etc. Sin embargo, el usuario aún querrá agregar validaciones
propias. Para esto es necesario identificar la llamada http que se
desea validar. Para agregar validaciones a la página de Actualizar
Datos solo hay que dar click derecho en la validación y seleccionar
‘Add Validation Rule’ del menú. Un caja de diálogo aparece con las
validaciones suministradas por la herramienta. Los tipos de valida-
ciones posibles incluyen: Form Field, Find Text, Maximum Request
Time, Required Attribute Value, Required Tag, y Response URL. Captura 3. Prueba con validaciones

La validación de Form Field verifica que un campo en la página ten-
ga el valor esperado. Un buen uso par esta validación se presenta
en los campos defaults. La validación de Find Text verifica la exis-
tencia o inexistencia de determinado texto en la página. Yo lo utili-
zo buscando con la opción “fallar si encuentra el texto”, para bus-
car mensajes de texto comunes en errores de programación. Hay
que recordar que la búsqueda solamente se hace a nivel HTML, así
que puede haber texto embebido en la página sin ser visible.
Es posible tener mayor control sobre la creación de Web Tests
mediante la utilización de Coded Web Tests. Estos son Web Tests
que se crean y existen en código. Para crearlos se puede utilizar
del botón designado o comenzando en blanco, haciendo uso
de las programación utilizando las librerías de WebTesting que
vienen con el paquete. También es posible programar extensio-
nes al producto, tales como reglas propias para la extracción y
validación del sistema.

La última validación nos permite fijar estándares de desempeño.

Puedes definir cuánto es el tiempo máximo permisible para que
cargue una página de tu aplicación. ‘Level’ es una propiedad co-
mún entre todas las reglas de validación. Cualquier web test puede
utilizarse durante pruebas de carga (load testing). Esta propiedad
determina cuando se incluirán en un escenario de pruebas de car-
ga. Como un bono, la herramienta de pruebas de carga (Load Tes-
ting) es incluida como parte del paquete de Test Edition.
Ejecutando la prueba con validaciones
Para ejecutar la prueba con validaciones, selecciona el botón de
ejecutar para que la prueba corra. El sistema proporciona informa-
ción para saber si la prueba pasa o falla. Para obtener un reporte
detallado de los resultados hay que seleccionar el link de ‘Test
run pass / fail’. Al hacer esto, el sistema proporciona el detalle
de todas las llamadas http con información acerca del estado del
navegador, datos de la requisición, respuesta obtenida, contexto
y detalles. Los detalles de nuestras validaciones se encuentran
en la tableta de detalles. En la muestra, una de las validaciones
falló. El sistema suministra el detalle de la falla. La presencia de
una sola falla de validación marcará toda la prueba como fallida.
Conclusión
La creación de Web Tests utilizando Microsoft Test Edition es
rápida, sencilla y eficiente. Debido a su dependencia en lla-
madas http e información HTML, es posible obtener resulta-
dos consistentes al ejecutar las pruebas minimizando así el
tiempo dedicado a la modificación de pruebas existentes.
La herramienta también proporciona la capacidad de ejecutar
pruebas de carga y performance sin ningún costo adicional.
Además de tener tremenda sinergia al utilizarse con Team Foun-
dation Server. Al utilizarse apropiadamente, los beneficios que
se pueden obtener con esta herramienta son muchos.
Espero la oportunidad de escribir más acerca de esto en
artículos futuros.
Si tienes alguna duda o sugerencia puedes comunicarte
conmigo en el correo benalonso@computer.org

www.sg.com.mx MAY-JUL 2009 15

 // PRODUCTOS /*tutorial*/

Aplicaciones en la Nube con Azure

Comprendiendo como funciona este nuevo esquema
Por Miguel Angel Morán y Misael Monterroca

El cómputo en la nube o cloud computing es una de las tendencias
que mayor impacto están teniendo en nuestra industria actualmente
y hacia el futuro próximo. A pesar de que en el número 22 de SG
ya se habló bastante sobre este tema, consideramos pertinente re-
pasar algunos puntos, y aprovechar para familiarizarnos con Azure,
que es la propuesta de Microsoft para una plataforma y sistema ope-
rativo para la nube.
Entendiendo la nube
Desde hace mucho tiempo, en la iconografía utilizada dentro de los
diagramas de topologías de redes, los trayectos donde viajan datos
a través de internet se representan como nubes para enmascarar la
complejidad del viaje a través de la red de redes. Derivado de esto,
la nube es una alegoría de internet y representa precisamente toda
la infraestructura que requiere internet para operar.
Cuando abstraemos este concepto e imaginamos la nube como una
unidad y no como cada una de sus piezas (protocolos, conexiones,
software, servidores, switches y un largo etcétera) tenemos el concep-
to al que actualmente se refiere la industria: Ver a internet como un
todo, donde dejan de ser importantes los detalles exactos para que
se logre echar a andar un aplicativo en internet, y conceptualizar a la
nube como una constante, como una infraestructura de facto con la
que podemos contar para utilizarla como plataforma de cómputo.
• Uso de estándares. Los estándares son importantes para lograr un
ecosistema eficiente en la nube y una interoperabilidad maximizada.
XML, SOAP y últimamente REST son hasta el momento los estánda-
res preferidos.
• Esquemas de pago basados en el consumo. Generalmente el soft-
ware se adquiere mediante licenciamiento al hacer un pago, usemos
o no usemos el software, el desembolso de dinero debe hacerse de
cualquier manera. En el modelo de precios de la nube se propone
que los pagos deben estar basados en datos del consumo real, por
ejemplo: porcentaje de utilización de los procesadores, accesos a la
base de datos, cantidad de hits por tiempo etc.
Como podemos apreciar, el objetivo del cómputo en la nube es dis-
minuir la complejidad y los costos asociados al generar aplicaciones
en Internet. Este concepto, a su vez hace uso de diferentes términos
ya utilizados en la industria. (Figura 1)

Por lo tanto, podemos definir el cómputo en la nube como la utili-

zación de internet (como un todo y no por piezas) para almacenar,
ofrecer y consumir servicios tanto de hardware como de software a
quien lo requiera.

El cómputo en la nube cuenta con varias características comúnmen-

te aceptadas:
• Tanto el hardware como el software son servicios. En los esque-
mas tradicionales es necesario hacer grandes inversiones para tener
un servidor en internet. En el esquema basado en la nube se renta
el hardware y el software donde se aloja nuestra aplicación, lo que
evita desembolsos iniciales.
• Infraestructura dinámica y autoadministrable. Del mismo modo,
en una plataforma no orientada a la nube, es necesario realizar la ad-
ministración de toda la infraestructura, desde el hardware, sistema
operativo, base de datos. Si se desea escalar la aplicación es nece-
sario hacer nuevas inversiones para ampliar o actualizar el hardware
para que soporte nuevas cargas además de tener que monitorear el
funcionamiento del hardware y de la red, actividades que usualmen-
te requieren de personal especializado, lo cual representa un costo.
En contraste, en la nube todo esto se ofrece como servicio y el pro-
veedor se encarga de hacer todo esto de una manera automatizada,
utilizando generalmente tecnologías de virtualización.
Figura 1. Conceptos que retoma el cómputo en la nube.
Clientes. Son los dispositivos que consumen los servicios de la
nube. Generalmente acceden a ellos mediante smart clients o pá-
ginas web.
Software como servicio. Se refiere a las aplicaciones de negocio
en sí. Son las aplicaciones que los desarrollares crean y exponen
a través de la nube. Es decir, cuando desarrollamos para la nube,
debemos exponer nuestro software como servicio (comúnmente
mediante web services y estándares web).
Plataforma como servicio: Se refiere a todo el software y herramien-
tas de administración que otorga el proveedor de servicios en la
nube para desarrollar y administrar las aplicaciones. Esto incluye los
SDKs, las consolas web para la administración de los recursos, y las
APIs (que a su vez, también son servicios) para comunicarse con la
infraestructura etc.

16 MAY-JUL 2009 www.sg.com.mx

Infraestructura como servicio: Es como tal el hardware que el pro-
veedor de servicios en la nube administra y facilita para el procesa-
miento y hospedaje de nuestra aplicación.
La plataforma de Servicios Azure: Una solución
completa para la nube:
La plataforma de Servicios Azure representa una propuesta integral para
resolver los retos que conlleva la implementación del cómputo en la nube.
La figura 2 representa los mismos conceptos que la figura 1, pero en base
al stack de tecnologías que conforman a Azure.
Figura 2. El stack de tecnologías que ofrece Azure
Las aplicaciones de negocio conforman el software como servi-
cio (SaaS) que creamos específicamente para la plataforma Azu-
re. Microsoft provee SDKs para diversas plataformas, como .NET,
Java o Ruby que contienen ejemplos y todo lo necesario para de-
sarrollar en la Azure, lo que permite utilizar todo el conocimiento
de los desarrolladores al utilizar lenguajes y sintaxis familiares.
Además existen herramientas para Visual Studio que permiten
integrar completamente la experiencia de programación al IDE de
Microsoft, que permite emular el ambiente de la nube, trabajando
de forma local. Al terminar el desarrollo el programador accede al
portal de administración de Azure y actualiza el proyecto para que
quede publicado.
Los servicios de Azure corresponden a la plataforma como servicio
(PaaS) lista para ser consumida que ofrece Microsoft para facilitar
enormemente las tareas comunes para desarrollar en la nube. Esta
plataforma ofrece los siguientes servicios:
• Live Services: Expone los servicios de Microsoft Live tales como
identidad, comunicación, presencia, búsqueda, sincronización, ubi-
cación geoespacial, etcétera.
• .NET Services: Proporciona bloques de código hospedados en la
nube listos para usarse. Es como tener la biblioteca de clases del .NET
www.sg.com.mx
Framework, sólo que expuesta en la nube. Proporciona servicios como
control de acceso, bus de servicios, flujos de trabajo entre otros.
• SQL Services: Proporciona una base de datos relacional consumi-
ble vía REST o SOAP expuesta en la nube.
• SharePoint Services: Otorga servicios de colaboración y persona-
lización para ser usados en la nube.
• Dynamics CRM: Da acceso por medio de la nube a los servicios de
Microsoft Dynamics.
Windows Azure
Windows Azure es el sistema operativo para la nube que se ejecuta
exclusivamente en los Dataservers de Microsoft. No es posible des-
cargarlo ni instalarlo en un servidor local. Windows Azure proporcio-
na abstracción de hardware, almacenamiento, monitoreo y actuali-
zación de los servicios, interoperabilidad de plataformas (.NET, Java,
Ruby, PHP, COM etc.) y representa la infraestructura como servicio
(IaaS) de Microsoft. Windows Azure asegura una disponibilidad
24/7 y se basa en reglas. La plataforma se encarga de la inmensa
mayoría de las tareas de mantenimiento y administración.
Windows Azure encapsula la plataforma con la cual se ejecuta, la
cual consiste de servidores virtualizados que ejecutan .Net 3.5 SP1,
IIS 7 y Windows Server 2008 64 bits en full trust. Es decir, los usua-
rios de Azure no tienen acceso directo al core de las máquinas vir-
tuales sino que acceden al sistema operativo mediante los servicios
expuestos por Windows Azure, mientras que Azure administra auto-
máticamente todo el hardware (redes, DNS, almacenamiento, balan-
ceo de carga, etcétera). Windows Azure además provee un servicio
básico de almacenamiento basado en blobs, tablas y colas hospe-
dadas en la nube. Podríamos decir que es el “sistema de archivos”
de Windows Azure.
La tecnología de Windows Azure ha sido probada ya en diferentes
servicios que ofrece Microsoft como Live Hotmail, es una plata-
forma madura que ha sido ahora expuesta a los desarrolladores
para su explotación.
Creando un “Hola SG”
Para empezar a trabajar de inmediato con Azure sólo es necesario
obtener e instalar las herramientas de Visual Studio para Azure. No
hay necesidad de registro en el sitio de Azure a menos de que se
desee publicar el servicio.
En este breve ejemplo crearemos un web cloud service básico.
1. Iniciemos Visual Studio 2008 (si se desarrolla en Windows Vista o
Windows 7, entonces es necesario ejecutarlo en modo administrador)
2. Dentro de Visual Studio 2008 seleccionar File -> New -> Project
3. En Project Types seleccionar “Cloud Service” y en los templates
seleccionar “Web Cloud Service”.
MAY-JUL 2009 17
 // PRODUCTOS /*tutorial*/

protected void Page_Load (object sender, EventArgs e) {

lblMensaje.Text = “Hola lectores de Software Guru”;
}

7. Antes de realizar la depuración de nuestro sitio, es necesario

establecer como proyecto de inicio el proyecto web (SGServicio-
EnLaNube_WebRole ). Finalmente realizamos la depuración de
nuestro proyecto, presionando F5 nuestro sitio web será desple-
gado en nuestro navegador predeterminado, como cualquier otra
aplicación ASP.NET

Figura 1. Creación de un nuevo proyecto para Azure en Visual Studio.

4. El template seleccionado, creará dos proyectos: SGServicioEnLa-

Nube que básicamente contiene los archivos de configuración de la
aplicación (las reglas que seguirá Azure para entregar el servicio)
y SGServicioEnLaNube_WebRole que simplemente es un proyecto
web tradicional (Asp.Net Web Project)
Figura 3. Creación de un nuevo proyecto para Azure en Visual Studio.
8. Mientras la aplicación se ejecuta, el systray muestra un ícono que
representa al programa “Development Fabric” que es un emulador
que simula el ambiente de hospedaje real de Azure, aunque lo hace
de manera local.

9. Para hospedar el servicio en Azure, debemos publicar el

proyecto y posteriormente seleccionar con el menú contextual
“Browse to Portal”.

10. Esto nos llevará al portal de Azure en internet (es necesario regis-
trarse previamente, y para poder publicar aplicaciones primero hay
que obtener un token). Seleccionamos New Project y posteriormen-
te Hosted Services

Figura 2. Arbol de elementos del proyecto.

5. El siguiente paso será abrir la página asp.net creada por default

y crear un control tipo “Label” al cual le agregaremos un mensaje
desde el code-behind:

<form id=“form1” runat=“server”>

<div>
<asp:Label runat=“server” id=“lblMensaje”></asp:Label>
</div>
</form>
Figura 4. Publicando la aplicación en Azure.
6. Abrimos el code-behind y en el evento Page_Load agregaremos un
mensaje a nuestro Label: 11. El portal de Azure posteriormente solicitará un nombre único
para la aplicación (único a nivel mundial).

Miguel Angel Morán (Twitter: @SrBichi) y Misael Monterroca (Twitter: @mmonterroca) son Microsoft Most Valuable Professionals (MVP) en C#. Cuentan con
13 años de experiencia desarrollando y lidereando soluciones de software de misión crítica en las más diversas industrias. Participan activamente en conferencias,
comunidades de desarrollo y divulgación tecnológica. Actualmente son consultores en emLink, empresa especializada en soluciones de software en las áreas de
movilidad, comercio electrónico y colaboración.

18 MAY-JUL 2009 www.sg.com.mx


Figura 5. Escogiendo el ambiente correspondiente.
12. Como podemos ver, Azure muestra los servidores de staging
(preproducción) y Producción. Al oprimir el botón Deploy el sis-
tema nos preguntará la ruta en el disco duro local en la cual se
encuentran los archivos generados en el paso 9 (con extensión .
cscfg y .cspkg) Al terminar de subirse dichos archivos, el sistema
publicará el proyecto y mostrará la ruta para acceder a la aplica-
ción en la nube.
13. Posteriormente dentro del portal es posible promover el sitio de
staging a producción.
www.sg.com.mx
Conclusiones:
La plataforma de servicios Azure provee una poderosa y
efectiva solución para desarrollar, administrar y hospedar
aplicaciones basadas en la nube, en cualquiera de sus capas
(software, plataforma e infraestructura), es una alternativa
real para generar aplicaciones escalables, interoperables
y con alta disponibilidad reduciendo significativamente la
inversión de tiempo y los costos. Proporciona además un
ambiente amigable para los desarrolladores, aumentando
su productividad derivado de los servicios “out of the box”
que la plataforma ofrece.
Referencias:
SDKs [microsoft.com/azure/sdk.mspx]
Services [microsoft.com/azure/services.mspx]
Herramientas de Azure para VS http:[is.gd/p3GV]
FAQs de Azure [microsoft.com/azure/faq.mspx]
Documentación para el desarrollo con Azure:
[msdn.microsoft.com/azure]
MAY-JUL 2009 19
 // ENTREVISTA

Jorge Zavala es un viejo lobo de mar en la creación y desarrollo de empresas de tecnología. Fue por ello que en el 2004 la Fundación
México Estados Unidos para la Ciencia (FUMEC) lo invitó para dirigir la oficina de TechBA en Silicon Valley, donde se dedica a apo-
yar a empresas mexicanas de tecnología que buscan penetrar el mercado global. Recientemente tuvimos oportunidad de platicar
con él para tratar de entender en qué consiste el DNA de Silicon Valley, y qué es lo que necesitan los empresarios mexicanos para
competir y trascender en este contexto.

20 MAY-JUL 2009 www.sg.com.mx

¿En qué consisten tus actividades en TechBA?
Básicamente tenemos tres actividades. La
primera es estar en contacto con la indus-
tria y los medios para identificar problemas
que pueden significar oportunidades de
negocio. En base a eso, buscamos empre-
sas mexicanas que potencialmente puedan
proveer soluciones para esos problemas y
hacer negocio. Por último, buscamos los re-
cursos de inversión para habilitar el negocio
en cuestión. Estos recursos pueden consistir
en fondos de los distintos programas de go-
bierno, o también capital de riesgo.
¿Cómo ha sido la experiencia de estar en
Silicon Valley?
Es un ambiente con características fabulo-
sas. Todos están buscando hacer el próximo
Google y las cosas suceden a una velocidad
impresionante. La gente quiere salir lo antes
posible con un producto en donde no nece-
sariamente está 100% terminado, pero tiene
una primera etapa que es suficientemente
útil y con perspectivas para desarrollarlo de
una manera efectiva. Aquí la gente no tiene
miedo a fracasar. Se utiliza un concepto que
me fascina denominado “fail fast” (falla rápi-
do). Es decir que si tienes una idea, la prue-
bes en el mercado lo antes posible; si la idea
es valiosa, corre a lograr el siguiente paso;
si la idea es mala o tiene que ser mejorada,
falla rápidamente y aprende de los errores.
¿Es viable replicar este modelo en otro lugar?
Muchos ya lo han intentado. Yo creo que a
final de cuentas el concepto sí es replicable.
Sin embargo, lo primero que necesitas es la
gente. Un error que se ha cometido en varios
países es que ponen los recursos financieros
por delante de la gente. Primero necesitas
a la gente con mentes frescas que genere
ideas y eso atraerá recursos.
¿Alguna decepción de Silicon Valley?
Pues no es una decepción de Silicon Valley
como tal, pero aquí me he dado cuenta que
en México perdí grandes oportunidades por
aferrarme a ideas por más tiempo del que
debía o por no tener una visión más am-
plia. Me he dado cuenta que es importante
ver las cosas en grande, y que los negocios
son para venderse, no para quedarse toda la
vida con ellos.
¿A qué te refieres con que los negocios son
para venderse?
Como empresarios debemos tener la actitud
de decir: “yo voy a arrancar esta idea, la voy
www.sg.com.mx
a llevar hasta donde llegan mis capacidades y
esas capacidades van a tener que ser releva-
das por alguien mas”. Pretender mantenerse
como fundador, dueño y director es un error
común en México. Por ejemplo en el caso de
Yahoo! los dos fundadores hoy tienen uno
el 3% y otro el 6% de la empresa, pero ese
pequeño porcentaje representa miles de mi-
llones de dólares. Pocas personas son un Bill
Gates que tiene la capacidad de tener una
buena idea, desarrollarla, llevarla al mercado
y administrarla por 30 años.
¿Cómo hacemos que las empresas en Méxi-
co sean atractivas para capital de riesgo?
Justamente esa es la razón por la que empe-
zó TechBA. La conclusión a la que hemos lle-
gado es que la razón por la que no tenemos
esas inversiones en México es porque no nos
ponemos metas tan grandes y no buscamos
esas grandes oportunidades.
Creo que hay tres elementos a considerar.
El primero es tener una visión global. Tene-
mos que salir a vender no lo que se vende en
México, sino lo que el mundo necesita en to-
dos lados. El segundo punto es que debemos
aprender a hacer un posicionamiento y dife-
renciación, encontrar nichos. Lo importante
no es hacer el producto más avanzado, sino
satisfacer una necesidad no resuelta. El tercer
punto es aprender a integrarse a una cadena
de valor. Hay que estar conscientes de que difí-
cilmente nosotros solos podemos llevar nues-
tro producto a todo el mercado.
Por otro lado, debemos romper el paradigma
de querer ser un país barato. Si volteamos
a ver, los iPod y los iPhones no son los más
baratos y aun así están causando estragos en
el mercado. Hay que buscar cómo posicionar
nuestros productos en un mercado donde ge-
neremos suficiente utilidad, y esa utilidad va a
atraer inversionistas. Si buscamos solamente
quedarnos con empresas de outsourcing de
TI que compitan por precio con las empresas
de India y China, pues vamos a tener un pro-
blema muy serio, porque somos más caros
(el costo de vida en México es más alto) y la
capacidad de generar utilidad va a ser menor,
y por lo tanto la inversión para empresas de
este tipo seguirá yéndose a otros países.
¿Cómo podemos fomentar la innovación?
Primero debemos entender que la innova-
ción no solamente se da en condiciones
científicas complejas, sino que se da en la
vida diaria. La innovación inicia cuando las
personas identifican problemas cotidianos y
platican al respecto con otras personas, ge-
nerando nuevas ideas. Este componente de
la discusión es muy importante y debemos
fomentar este tipo de interacción.
En TechBA llevamos a cabo “espacios de in-
novación”, que son sesiones en las que nos
juntamos con 20 ó 30 empresas y discutimos
sobre algún tema para generar alternativas
de solución y oportunidades de negocio.
Otro ejemplo son los eventos como los Super
Happy Dev Houses que ya se están haciendo
en México, donde un grupo de programado-
res se juntan y aprenden a hacer algo, pero
también discuten sobre cómo mejorarlo. De
un evento de estos salió la idea para el pro-
yecto Twirex (www.twirex.com), de una dis-
cusión sobre la dificultad en twitter para dar
seguimiento a temas específicos. Este tipo
de proyectos no necesariamente requiere de
gigantescos recursos tecnológicos, sino de
la habilidad de comunicación, de síntesis y
de crear nuevos conceptos.
En México todavía creemos que cuando te-
nemos una nueva idea o producto, la forma
de mantener la ventaja competitiva es es-
conderlo de los demás. Esto es una pérdida
porque al esconderlo le quitamos la posibi-
lidad de probarlo y fallar rápido. He tenido
discusiones con empresarios mexicanos que
han venido a verme y me dicen “es que no te
puedo decir la idea que traigo, porque no sé
si me la vas a copiar”. La verdad es que si en
una plática de diez minutos alguien puede
copiar tu idea y hacerla mejor, entonces tu
idea no vale nada, y lo mejor es que te ente-
res antes de dedicarle muchos recursos.
¿Qué mensaje le dejas a los lectores de SG?
Lo que más deseo ver en los lectores de SG
es un abierto interés por conquistar nuevos
mundos y demostrar la gran capacidad que
hay en los emprendedores mexicanos para
conquistar nuevos mercados. México está
lleno de problemas que se pueden convertir
en grandes oportunidades para satisfacer
necesidades que atañen no solo a los mexi-
canos sino a personas de todo el mundo.
Es hora de alimentar nuestras propias moti-
vaciones y transformar las inquietudes que
todos tenemos dentro y que al liberarlas se
conviertan en oportunidades invaluables
donde podemos dejar nuestra huella y lograr
nuestra realización personal.
MAY-JUL 2009 21
22 MAY-JUL 2009 www.sg.com.mx
 Si eres uno de tantos desarrolla-
dores que lleva años queriendo
aprender a hacer aplicaciones
para teléfonos móviles pero no
ha tenido oportunidad de hacerlo, más
vale que no dejes pasar más tiempo.
En los últimos meses se han conjuntado distintos
factores que han detonando la importancia (y por lo
tanto la rentabilidad) de las aplicaciones de software
en dispositivos móviles, especialmente el segmento
de smartphones. Algunos factores tienen que ver con
avances tecnológicos, otros con estandarización, y
otros más con nuevos modelos de negocio.

Es así que en esta época de conectividad de banda an-

cha, servicios de localización, plataformas multi-dis-
positivo y tiendas de aplicaciones en línea, el momen-
to ha llegado para desarrollar aplicaciones para estos
dispositivos y debes aprovechar la oportunidad.

En las siguientes páginas te presentamos distintos

artículos que van desde un repaso histórico de las
tecnologías, a artículos técnicos para plataformas
específicas y análisis de oportunidades de negocio.

www.sg.com.mx MAY-JUL 2009 23

 Un vistazo al pasado y presente del smartphone
por Germán Domínguez
Aunque los smartphones parezcan un ícono
de apenas los últimos años, en realidad estos
dispositivos tienen ya bastante camino recorri-
do. Conozcamos un poco sobre su evolución y
cómo hemos llegado a lo que tenemos ahora.
Referencias:
www.wikipedia.com En 1983 Casio lanzó el PF-3000, que fue el pri-
www.palmsource.com mer “diario digital”. Esta era una calculadora
www.byte.com digital que incluía capacidades para agenda
telefónica, calendario y memo (notas).
24 MAY-JUL 2009
Por otro lado, desde 1987 las comunicaciones
celulares se activaron en México. En esos mo-
mentos teléfonos como el Motorola DynaTac de
dimensiones similares a un ladrillo y pantalla de
una línea abrían el camino en esta industria.
En el 1992, IBM presentó el primer smar-
tphone, conocido como IBM Simon Personal
Communicator; vendido en Estados Unidos
por BellSouth. Este dispositivo ya incluía ca-
pacidades de agenda, calendario, calculado-
ra, correo electrónico, envío/recepción de fax,
pantalla táctil y escritura predictiva. Era un
dispositivo muy avanzado para su época.
www.sg.com.mx
El Apple Newton, lanzado en 1992, es conside-
rado como el primer PDA (Personal Digital Assi-
tant). De hecho, fue Apple quien acuñó este tér-
mino para referirse al Newton. Este dispositivo
contaba con un sistema operativo desarrollado
en C++ e integraba funciones para envío e im-
presión de documentos, procesador de pala-
bras, agenda, calendario y calculadora. Adicio-
nalmente, permitía el desarrollo de aplicaciones
personalizadas mediante un lenguaje de pro-
gramación propietario llamado NewtonScript.
El ambiente de desarrollo para aplicaciones en
Newton tenía un costo inicial de $1,000 dólares
y sólo era soportado en sistemas Macintosh, lo
cual limitó su popularidad. Eventualmente fue
licenciado como shareware y finalmente sin
costo, soportando adicionalmente Windows.
En 1996 Palm Computing lanza su línea Pilot.
Éstos eran dispositivos monocromáticos, al-
gunos sin iluminación en la pantalla ni puerto
de comunicaciones infrarrojo, con capacidad
de almacenamiento que fluctuaba desde los
128kb hasta 1Mb de memoria. Las “Pilot” rá-
pidamente se hicieron populares por su precio
y el sistema de reconocimiento de escritura
conocido como Graffitti. Las funcionalidades
esenciales de los PDAs empezaban a estan-
dardizarse: todos deberían de incluir cuando
menos agenda, calendario, bloc de notas y cal-
culadora. Durante estos tiempos, el desarrollo
de aplicaciones estaba basado en C; el IDE
preferido para Palm era CodeWarrior de Me-
trowerks, un ambiente de desarrollo original-
mente creado para Macintosh que fue portado
posteriormente a Windows.
En 1998 se acelera la carrera de los PDAs con
la incursión en el mercado de HP y su línea Jor-
nada. Estos dispositivos estaban basados en el
sistema operativo Windows CE y tenían capa-
cidades iniciales de 16MB de RAM, pantalla a
color VGA y modem integrado. Las aplicaciones
se desarrollaban en lenguajes de programa-
ción como Embedded Visual Basic (eVB) y Em-
bedded Visual C++ (eVC) usando un ambiente
basado en Visual Studio conocido como Micro-
soft Embedded Tools.
Los primeros esfuerzos para integrar comuni-
caciones inalámbricas en los PDAs se dieron a
principios de esta década. En 2001, el Hands-
pring Visor ya soportaba un módulo de ex-
tensión llamado VisorPhone que lo habilitaba
como teléfono usando la red GSM. En el 2002
Handspring lanzó el Treo 180, que ya integraba
capacidades de teléfono celular sin necesidad
de dispositivos externos.
Germán Domínguez es Licenciado en Informática Administrativa de UNITEC con más de 13 años de experiencia en el desarrollo de aplicaciones de
negocio y aplicaciones Web. Ahora pertenece al equipo de IT de IBM de México, especialista para la marca de software Rational, y puede ser contactado
en germand@mx1.ibm.com
www.sg.com.mx
En el 2002 Research in Motion introduce al mer-
cado los primeros dispositivos BlackBerry que
incorporaban correo electrónico y telefonía ce-
lular. Esta capacidad integrada de correo elec-
trónico y telefonía móvil, hizo del BlackBerry el
primer dispositivo completamente integrado y
optimizado para comunicaciones inalámbricas.
Como consecuencia del incremento de pla-
taformas y funcionalidades, durante este
periodo los lenguajes de programación y
ambientes de desarrollo para smartpho-
nes aumentaron significativamente. Surgen
RADs (Rapid Application Development) para
dispositivos móviles, el más destacado: Sa-
tellite Forms que permite el diseño visual de
formas y pantallas para PalmOS y Windows
Mobile. Los lenguajes tradicionales de desa-
rrollo para dispositivos móviles se consoli-
dan, pero también los lenguajes modernos
comienzan a permear: Java 2 Micro Edition,
.Net Compact Framework, Python. Esto trae
como consecuencia que el universo de desa-
rrolladores para dispositivos móviles crezca
significativamente, y con ello la cantidad de
aplicaciones disponibles.
Durante los años 2003-2007, los fabricantes
tradicionales de PDAs pasaron por momentos
de silencio, seguían produciendo dispositivos
con las mismas características, aunque incre-
mentaban las capacidades de procesamiento
y almacenaje. Palm produce nuevas versiones
de Treo, algunas con el sistema operativo Pal-
mOS y otras con Windows Mobile. HP tampoco
incorpora grandes innovaciones, más allá de
incorporar lectores de huella digital. BlackBe-
rry se consolida en el mundo corporativo con
su integración segura con el correo corporativo
mediante su BlackBerry Enterprise Server. Por
el lado de los fabricantes de teléfonos, Nokia
incursiona en el sector de smartphones con
la serie N iniciada con el modelo N70, basado
en el sistema operativo Symbian, incorporaba
pantalla a color, cámara fotográfica, soporte de
aplicaciones Java, mensajes multimedia, nave-
gador Opera, radio y tonos polifónicos. Con esto
se inicia una carrera entre los fabricantes de te-
léfonos celulares para brindar cada vez mayor
convergencia en sus dispositivos. Por su parte,
durante esta etapa los proveedores de redes ce-
lulares se dedicaron a madurar sus tecnologías
y prepararse para la migración hacia GSM y 3G.
El letargo se rompe en 2007 cuando Apple
lanza al mercado el iPhone, el cual asombró al
vender más de 270,000 dispositivos en las pri-
meras 30 horas. Una de las características mas
importantes del iPhone es su sistema operativo
propietario con una interfaz de usuario única y
un acelerómetro integrado, que permite cam-
biar la posición de la imagen en la pantalla de
acuerdo con la posición física del teléfono.
Adicionalmente, el teléfono reconoce “gestos”
realizados con los dedos sobre la pantalla, para
ejecutar acciones.
En 2008 en México los principales proveedores
de telefonía celular habilitan su red para sopor-
tar GSM / 3G lo cual abre el camino para nuevos
dispositivos y servicios.
Apple libera el iPhone SDK, a través del cual se
pueden desarrollar aplicaciones para el iPhone
usando el ambiente de desarrollo XCode. Asi-
mismo, Apple abre su “App Store”, una tienda de
aplicaciones en línea donde los desarrolladores
pueden ofrecer sus aplicaciones para que sean
compradas y descargadas por los usuarios. En
poco más de 9 meses de existencia, el iPhone
App Store acumula más de 35,000 aplicaciones
y ha superado el billón (mil millones) de descar-
gas. Queda claro que el impacto de este modelo
para ofertar aplicaciones. Tanto así que el resto
de los proveedores, desde Microsoft hasta Re-
search in Motion, ya han anunciado sus propios
“app stores”.
También en el 2008 se libera Android, una
plataforma “open source” para smartphones.
Detrás de éste lanzamiento están Google, In-
tel, eBay y otros que forman el Open Headset
Alliance. Android está basado en el sistema
operativo Linux y las aplicaciones se progra-
man en Java, lo que lo hace atractivo a una
gran cantidad de desarrolladores.
En el 2009, el ritmo se ha acelerado aun más.
Apple ya liberó el beta del iPhone SDK 3.0,
Android ya se encuentra en versión 1.5, y para
cuando leas estas líneas Microsoft ya habrá
liberado la versión 6.5 de Windows Mobile, la
cual incorpora capacidades de cómputo en la
nube. Antes de que termine el verano Palm lan-
zará el Palm Pre con el nuevo sistema operativo
WebOS, en el cual las aplicaciones se desarro-
llan usando tecnologías sencillas y conocidas
como HTML, Javascript y CSS.
Aún hay mucho material adicional que cubrir,
tecnologías, productos y nuevos lanzamien-
tos. Pero al final nuestra labor como desa-
rrolladores es mantenernos actualizados. El
reto es encontrar la aplicación del billón de
dólares que por más de 10 años se ha busca-
do para esta industria.
MAY-JUL 2009 25
 Un modelo con alto potencial en aplicaciones móviles
por Héctor Obregón
Hace varios años el concepto de aplicacio-
nes peer to peer en Internet se popularizó
y dio origen a una amplia variedad de solu-
ciones que ya forman parte de nuestra vida
diaria, tales como Messenger, Windows Live
Sync, Skype y BitTorrent entre otras.
¿Qué es peer to peer?
En un modelo peer to peer necesariamente
participan dos o más colegas (peers) co-
rriendo en dispositivos –la mayor parte de
las veces una PC– que se comunican direc-
tamente entre si en un modelo uno a uno o
muchos a muchos, sin pasar a través de un
servidor central para la parte medular de la
interacción entre ellos.
En la mayoría de las aplicaciones peer to
peer un servidor central actúa únicamen-
te como un directorio que le permite a los
diferentes peers encontrarse entre sí. Por
ejemplo, cuando quiero llamar a alguien
a través de Skype, mi PC obtiene las di-
recciones de mis contactos de un servidor
central que conoce las ubicaciones de
todos. Sin embargo, una vez que inicio la
26 MAY-JUL 2009
llamada todos los datos de esta se inter-
cambian mediante una conexión directa
entre mi PC y la del contacto con el que
estoy hablando. Los datos de la llamada
ya no fluyen a través del servidor central.
Este esquema se conoce como peer-to-
peer “suave”.
En un modelo peer to peer puro o completo,
no hay distinción entre cliente y servidor y
todas las funciones de indexación y localiza-
ción están a cargo de los mismos clientes.
Las principales ventajas de este modelo son
su escalabilidad y resistencia a fallas. Dado
que cada peer funge tanto como cliente
como servidor, agregar nodos a la red impli-
ca incrementar casi linealmente los recursos
disponibles de cómputo y comunicaciones.
Adicionalmente, como ningún nodo juega un
rol especial, la pérdida o falla de uno normal-
mente no afecta el funcionamiento de la red
global que sostiene a la aplicación. BitTorrent
es un excelente ejemplo de un protocolo peer
to peer que es altamente escalable, resisten-
te y prácticamente imposible de controlar por
una autoridad central.
El escenario móvil
Hoy existen pocas aplicaciones móviles con
un modelo de este tipo que verdaderamente
aprovechen los diferenciadores de un dispo-
sitivo móvil. Es cierto que hay versiones móvi-
les de Skype o Messenger, pero en mi opinión
hay un amplio terreno sin explotar en aplica-
ciones móviles peer to peer.
Cuando hablamos de soluciones para movili-
dad, tenemos que ir más allá de hacer lo mismo
que hacíamos en la PC pero ahora en pequeño.
El diferenciador obvio de un dispositivo móvil
es….. ¡que se mueve! La ubicación se vuelve
relevante para que pensemos en aplicaciones
móviles peer to peer que verdaderamente ha-
gan sentido.
La ubicación tiene dos connotaciones:
1. ¿Dónde estamos ubicados en el planeta? De-
finido por nuestras coordenadas – latitud, longi-
tud y altura – obtenidas mediante alguna forma
de posicionamiento – GPS, trangulación, etc. –
2. ¿Quién está cerca de mi? En este caso no es
necesario conocer nuestra posición absoluta,
el simple hecho de poder identificar qué es lo
www.sg.com.mx
que está cerca de mí puede proveerme con
información interesante.
Es en la convergencia del modelo peer to peer
con la información de nuestra ubicación absolu-
ta y relativa donde está el verdadero potencial
de innovación en aplicaciones móviles. Pense-
mos en algunos ejemplos ...
Un automóvil podría comunicar a cualquier
otro cercano que ha sufrido un accidente. Es-
tos a su vez podrían retransmitir esta informa-
ción a otros de tal forma que conductores que
se acercan al punto del problema sean adver-
tidos. Podría funcionar incluso para compartir
información de las condiciones de tráfico que
nos ayuden a elegir mejores rutas.
Cuando llego a un concierto o una fiesta con
intención de conocer a alguien, mi celular po-
dría establecer contacto con la gente que está
a mi alrededor comunicándole mis intencio-
nes y preferencias. Lo mismo si quiero jugar
a algo con alguien que se encuentre cerca.
La función social de compartir música de la
Microsoft Zune a través de Wi-Fi es una idea
adelantada a su tiempo que no ha funcionado
mejor simplemente por la falta de una masa
crítica de dispositivos.
En un parque de diversiones podría calificar en
mi celular las diferentes atracciones que visito
y consultar en tiempo real lo que piensan otros
visitantes al parque sobre ellas. Si les gustaron
o no y además como están los tiempos de espe-
ra en las colas. Esto último podría resolverse sin
mayor interacción humana si los dispositivos
simplemente analizan su densidad relativa en
un área determinada.
Retos a resolver
Hay varios obstáculos que dificultan el desarro-
llo de este tipo de aplicaciones en este momen-
to y que nos tocará ir resolviendo.
Diversidad de plataformas móviles. El mer-
cado de dispositivos móviles es altamente
competitivo y ningún jugador tiene una pe-
netración suficientemente dominante como
para ser un estándar generalizado. El valor
de uso de una aplicación peer to peer (como
el de cualquier otra red) se incrementa con-
forme agregamos más participantes a ésta.
Es el problema que mencionaba sobre las
Héctor Obregón es fundador y Director General de emLink. Héctor se especializa en el desarrollo de soluciones móviles y para dispositvos embebidos.
Adicionalmente, es Microsoft MSDN Regional Director, Microsoft MVP para Windows Embedded y miembro del comité de dirección de la Comunidad
.NET de México D.F.
www.sg.com.mx
funciones sociales del Microsoft Zune. Para
poder realmente aprovecharlo tengo que
encontrarme con usuarios de Zune segui-
do y en muchos lados. Si queremos crear
una aplicación peer to peer de alto impac-
to seguramente tendremos que soportar a
todas las principales plataformas móviles
y este es un esfuerzo no trivial. El proble-
ma además se incrementa si consideramos
que hay tremenda variabilidad entre las
capacidades de los diferentes modelos de
dispositivos móviles. Hay mucho menos
diferencia de capacidades entre una Mac y
una PC de la que existe entre un teléfono
básico y un smartphone avanzado. Para mi-
tigar este problema podemos dirigir nues-
tra aplicación a las necesidades de un nicho
de mercado específico que tienda a utilizar
predominantemente un sistema operativo
móvil o bien podemos simplificar nuestra
aplicación al mínimo común denominador.
Configuración compleja de redes locales. Los
sistemas operativos móviles deben evolucio-
nar de tal forma que sea más sencillo estable-
cer una conexión local entre dispositivos. Las
modalidades existentes a través de Bluetooth
o Wi-Fi no son suficientemente sencillas aún.
Ambas plataformas inalámbricas son sufi-
cientemente buenas en términos de ancho
de banda y alcance para muchos usos, pero
hay que simplificar la experiencia de usuario
para establecer una conexión. Todos los de-
talles del protocolo deben esconderse de tal
forma que para el usuario sea tan fácil como
responder a una pregunta como “Juan desea
establecer una conexión contigo para jugar
Scrabble. ¿Estás de acuerdo?” Con respon-
der a esa pregunta mi dispositivo debiera de
hacer todo lo necesario para establecer una
conexión segura, instalar el scrabble si no lo
tengo e iniciar el juego.
Protección de la privacidad. Muy relacionado
con el punto anterior, necesitamos tener con-
trol absoluto de con quién queremos compar-
tir nuestra información. Resulta particular-
mente sensible la información sobre nuestra
ubicación absoluta. Hay muchos escenarios
done el usuario puede no querer ser ubicado.
Las plataformas móviles nos deben dar con-
trol total sobre nuestra información al mismo
tiempo que nos permitan compartirla de ma-
nera simple con quien o quienes deseemos.
Plataformas cerradas. Cuando hablamos de
dispositivos móviles más allá del celular, por
ejemplo el automóvil, no hay mucho que ha-
cer mientras las plataformas de los dispositi-
vos de a bordo continúen estando cerradas.
Hay una oportunidad para los fabricantes de
autos para ofrecer un “sandbox” dentro de
la computadora de a bordo donde desarro-
lladores independientes pudieran agregar
sus aplicaciones. Mientras tanto el ritmo de
innovación dependerá de lo que cada fabri-
cante pueda hacer por su cuenta.
Servicios estándar de descubrimiento geográ-
fico. Necesitamos un DNS de descubrimiento
geográfico. Un servicio totalmente estandariza-
do y abierto que me permita descubrir con faci-
lidad cualquier tipo de objetos y servicios que
estén disponibles en una cierta zona geográfica
o en mi vecindad próxima para poder iniciar una
interacción con ellos. En Internet el DNS hace la
función indispensable de un directorio de nom-
bres y es la base de mucho de lo que hacemos
en la red. Un servicio similar que incorporara
información geográfica, potenciaría de manera
fundamental la innovación en el espacio móvil.
El reto no es nada trivial ya que la información
geográfica cambia mucho más rápido que la de
nombres en Internet, además de que hay mu-
cho más dispositivos móviles que computado-
ras en el mundo.
Por dónde empezar
Aún cuando los retos que hemos mencionado
arriba son significativos, las herramientas ne-
cesarias para crear la primera generación de
aplicaciones móviles peer to peer realmente
innovadoras ya existen. No hay que perder
de vista que el mercado para este tipo de
aplicaciones es más grande que el que exis-
te hoy para computadoras personales. Las
principales plataformas móviles (Symbian,
Windows Mobile, Blackberry e iPhone OS) to-
das cuentan con herramientas de desarrollo
poderosas y gratuitas que podemos utilizar
para empezar a construir estas aplicaciones
hoy. Es muy probable que el primer gran éxito
de este modelo no se trate de una aplicación
compleja. Sucedió de forma similar en las PCs
con ICQ y Napster en su momento. No sé cual
será la primera aplicación ni en que momento
estará disponible, pero estoy absolutamente
seguro de que llegará y cambiará nuestra for-
ma de vivir para siempre.
MAY-JUL 2009 27
 Una interesante oferta para desarrollo móvil
por Edgar Parada
Hace tiempo que observamos un fenómeno
que consiste en una evolución de las aplica-
ciones web tradicionales hacia un entorno
de aplicaciones que se apoyan de un cliente
enriquecido vía plug-in o stand-alone para
entregar una experiencia similar a la de una
aplicación de escritorio pero con la ventaja
de estar conectadas al Internet e interactuar
con los datos en la nube de forma transpa-
rente. Este tipo de aplicaciones se conocen
como RIAs (Rich Internet Appications), y este
modelo ha sido liderado por tecnologías
como Java, Flash y últimamente Silverlight.
Dadas las capacidades de conectividad y
procesamiento de los smartphones moder-
nos, son un tipo de cliente muy atractivo
para RIAs móviles, y las diferentes piezas se
están acomodando para lograr esto:
Los operadores (carriers) están empujando
agresivamente nuevos modelos con mayor
funcionalidad y mejores planes de datos.
Los fabricantes están facilitando la interac-
ción con sus dispositivos mediante la dispo-
nibilidad de APIs y SDKs.
Las principales plataformas tecnológicas
para desarrollar software cuentan con edi-
ciones y componentes específicos para dis-
positivos móviles. Asimismo, los ambientes
de desarrollo modernos como NetBeans,
Flash IDE y Visual Studio entre otros, ya
cuentan con herramientas orientadas a fa-
cilitar el desarrollo en smartphones, tales
como emuladores y perfiladores (profilers)
de memoria.
En resumen, las aplicaciones móviles enri-
quecidas son un segmento que representa
una gran oportunidad.
28 MAY-JUL 2009
Tecnologías para RIAs móviles
Existe un buen número de tecnologías dispo-
nibles para desarrollar aplicaciones móviles.
Las que tienen mayor tiempo y posiblemen-
te más adeptos son Java Micro Edition y C++
(BREW/Symbian).
Por otro lado, está surgiendo una nueva
generación de tecnologías para RIAs mó-
viles. Entre estas destacan Flash Lite, el
iPhone SDK y la plataforma Android. Per-
sonalmente, la que más me convence de
éstas y que les puedo recomendar es Flash
Lite. En el resto de este artículo ahondaré
sobre esta tecnología.
Antes de entrar de lleno a Flash Lite, quie-
ro hacer mención de un par de tecnologías
para RIAs móviles que pudieran ser una
buena opción una vez que sean liberadas.
La primera es Palm WebOS que será libera-
da este verano, y la segunda es Silverlight
for Mobile que se espera esté disponible
con Windows Mobile 7 el próximo año.
Conociendo Flash Lite
Flash Lite consiste en una versión reducida de
la plataforma Flash, diseñada para dispositi-
vos móviles. Dadas sus capacidades y su ubi-
cuidad, ésta puede ser una plataforma muy
atractiva para quienes busquen desarrollar
aplicaciones para dispositivos móviles. Adi-
cionalmente, gracias al “Open Screen Project”
Flash pronto estará disponible en televisores
y otros dispositivos de consumo, lo cual lo
hace aun más atractivo para desarrolladores
tratando de entrar a nuevos nichos.
Flash Lite ya tiene bastante camino recorri-
do. La versión 1.0 fue lanzada en el 2003 con
el aparato 505i de NTT DoCoMo en Japón.
La adopción de Flash Lite tuvo gran éxito en
éste país y rápidamente otros operadores
y dispositivos soportaron esta tecnología.
Sin embargo, en el resto del mundo Flash
Lite tardó en penetrar. Tal vez Macromedia
(quien en ese entonces era dueño de Flash)
equivocó su estrategia al tratar de impul-
sar Flash Lite por medio de los operadores
(carriers). Macromedia se encontró con el
fenómeno denominado “Walled Garden”,
el cual implica que los operadores con el
fin de proteger un mercado que parecie-
ra seguro impiden el rápido avance de
las tecnologías emergentes. Una vez
que Adobe adquirió Macromedia en el
2005 cambiaron la estrategia, buscan-
do empujar Flash Lite por medio de
los fabricantes de teléfonos móviles
y encontrando una buena respues-
ta por parte de Nokia, Samsung,
Sony Ericsson y Motorola entre
otros. Fue así que a finales del
2006 se hicieron disponibles en
nuestro lado del mundo los pri-
meros dispositivos con sopor-
te a Flash Lite, y actualmente
ya existe una gran oferta de
dispositivos que soportan
esta tecnología.
Más información:
Project Capuchin
tinyurl.com/5jypyc
Kuneri Lite
www.kunerilite.net
Blocket PC Open Source:
opensource.blocketpc.com
SWX Format
swxformat.org
www.sg.com.mx
Flash Lite actualmente se encuentra dis-
ponible en su versión 3.0. Su arquitectura
consta de varios componentes que permi-
ten a las aplicaciones y al contenido Flash
interactuar con el ambiente local. El motor
de rendereo de gráficas es capaz de in-
terpretar imágenes en diversos formatos
bitmap y vectoriales. También hay compo-
nentes específicos para el procesamiento
de ciertos tipos de datos, imágenes, vi-
deo, señales de la red celular y la batería.
El comportamiento de las aplicaciones y el
manejo de eventos se programa por medio
del lenguaje ActionScript.
Edgar Parada es Director de Activ (www.activ.com.mx), un Adobe Authorized Training Center especializado en tecnologías como Flex, Flash Lite y Flash
Media Server. Es manager de Riactive (www.riactive.com.mx), el grupo de usuarios oficial en México para Flex. edgarparada@activ.com.mx
www.sg.com.mx
Proyectos complementarios a
Flash Lite
En base a las fortalezas y debilidades de
Flash Lite han surgido diversos proyectos
complementarios. Listo a continuación los
que considero más significativos:
Proyecto “Capuchin” de SonyEricsson. Per-
mite manejar la interfaz de usuario en Flash
Lite mientras que la lógica de datos se pro-
grama con Java ME. Los datos se pueden
transmitir bidireccionalmente entre Java ME
y Flash Lite por medio de APIs especiales.
Kuneri Lite. Es una herramienta RAD para ex-
tender las capacidades de Flash Lite, propor-
cionando acceso a protección de software,
timers, acceso al sistema de archivos, Blue-
tooth, Cámara, GPS y tonos DTMF.
BlocketPC. El grupo de usuarios hispano de
Adobe Mobile ofrece un par de proyectos
open source denominados Layout Manager
y Feather Framework que sirven para adap-
tar contenidos a los diversos tamaños de
pantallas e incluso cambios de orientación.
SWX. El formato de datos más simple para
trabajar con Flash.
Adobe mismo tiene proyectos para pro-
mover el uso de esta tecnología. Entre
los más destacados están: Photoshop.
com para dispositivos móviles, Adobe
Mobile Packager para facilitar el empa-
quetamiento de las aplicaciones, y Adobe
AppZone que es una plataforma similar
a la AppStore de Apple para que los de-
sarrolladores puedan comercializar sus
aplicaciones.
Soporte a Flash Lite en
nuestra región
En México y otros países de América Latina ya
existe una buena oferta de smartphones con un
buen soporte de Flash Lite. Mención especial
merece el modelo N5800 recientemente libera-
do por Nokia, que es el primero que provee API
de servicios Flash Lite de localización, acceso a
contactos, calendario y mensajería entre otras
funciones que elevan al máximo las posibilida-
des de desarrollo con esta tecnología.
Vale la pena mencionar que Flash Lite no solo
es soportado en smartphones, sino también
en otros dispositivos como el Nintendo Wii y
el Playstation 3.
Para una lista completa de dispositivos que
soportan Flash Lite les recomiendo revisar
www.adobe.com/mobile/supported_devices
Conclusiones
Después de conocer todos los proyectos y
características de esta tecnología es relati-
vamente más sencillo identificar oportuni-
dades de negocio para llevar la experiencia
móvil al siguiente nivel.
Espero que el público lector sea sensible a
toda esta revolución y descubra una oportu-
nidad más en el desarrollo para móviles. Es
muy buen momento para experimentar con
tecnologías RIA para smartphones.
MAY-JUL 2009 29
 ¿Por dónde empezar?
Por Juan José Karam
Cumpliendo casi un año en nuestro País,
el teléfono producido por la empresa de
la manzana ha empezado a tomar fuerza
a través de sus aplicaciones, tanto en el
aspecto casual en el cual podemos en-
contrar aplicaciones para consultar la
cartelera del cine, video juegos e incluso
revistas digitales, hasta el entorno em-
presarial con lectores de noticias, mane-
jo de finanzas, entre muchos otros. Esto
ha generado una oferta de trabajo nueva
para el mercado mexicano: ingenieros de
software con perfil para desarrollar tanto
para Mac OS X como para iPhone OS.
Aprender a desarrollar para iPhone puede te-
ner muchas oportunidades, la más tentadora
por supuesto es vender nuestras aplicaciones
en la App Store aunque también la necesidad
de software a la medida empresarial comien-
za a crecer. Cualquiera que sea tu motivación,
esto puede traerte una gran retribución.
¿Qué necesito?
Una computadora Apple con procesador Intel.
El iPhone SDK que es la plataforma de desa-
rrollo para iPhone OS. Esta es gratuita y se
puede descargar desde el sitio de Apple De-
veloper Connection (developer.apple.com).
Aunque la plataforma de desarrollo nos pro-
porciona un simulador de iPhone bastante
confiable, es recomendable tener ya sea un
iPod Touch o un iPhone.
Estar inscrito en el iPhone Developer Pro-
gram Standard el cual nos permitirá instalar
la aplicación en nuestros dispositivos, como
también permite el acceso a la App Store
como medio de distribución.
Conociendo la plataforma
Es importante conocer primeramente cuales
son las características de la plataforma, desde el
lenguaje de programación hasta los frameworks
que se utilizan en el desarrollo de iPhone.
30 MAY-JUL 2009
Objective-C
Objective C es el lenguaje de programa-
ción utilizado para programar aplicacio-
nes para iPhone. Es un lenguaje orientado
a objetos creado en los años ochenta por
la empresa Stepstone y posteriormente
licenciado por NeXT Computer. Estos últi-
mos extendieron el lenguaje de varias ma-
neras, por ejemplo creando los NeXTStep
frameworks que preceden a Cocoa. Pode-
mos entender a Objective-C como una ex-
tensión del ANSI C, lo cual nos permitirá
utilizar todos los beneficios de C. Gracias
a esto podemos implementar clases en un
paradigma orientado a objetos o también
hacerlo de manera estructurada.
Aunque podemos definir que C# o Java tie-
nen sus orígenes en C o C++, la sintaxis de
Objective-C puede causarnos confusión en
un principio, como ejemplo podemos anali-
zar las siguientes líneas de código:
Sintaxis Objective-C
(NSEvent *)nextEventMatchingMask:
(unsigned int)mask untilDate:(NSDate *)
expirationDate inMode:(NSString *)mode
dequeue:(BOOL)dequeue
Representación en C#
nextMatchingEvent(int mask,
NSDate expiration, String mode, boolean flag);
A pesar de que son expresiones que en el
fondo pueden interpretarse como la mis-
ma, las sintaxis son totalmente distintas.
Por lo tanto nuestra primera recomenda-
ción es estudiar bien el lenguaje, esto
debido a que puede agregarnos un grado
mayor de complejidad durante el proceso
de aprendizaje.
Una referencia útil es el tutorial “Object-
Oriented Programming with Objective-C”
disponible en developer.apple.com/iphone
donde se explican a detalle las particularida-
des del lenguaje.
Arquitectura
Para entender
a grandes rasgos
el funcionamiento
del dispositivo, y más
importante, cómo es que
nuestra aplicación convive con
el mismo, debemos conocer como
funciona la plataforma y qué partes la com-
ponen. Similar al Mach Kernel encontrado
en Mac OS X, se encuentra el componente
más importante: el Kernel de iPhone OS. En-
cima de éste se encuentran diversas capas
las cuales nos proporcionan los servicios
que darán vida a nuestra aplicación.
Cocoa Touch
Media
Core Services
Core OS
Figura 1. Arquitectura del iPhone SDK
Core OS. Rodeando al Kernel, los drivers
y las interfaces del sistema operativo,
ésta capa nos ofrece la oportunidad de
acceder a las características de bajo nivel
como pueden ser las más importantes: hi-
los, uso de la red, acceso al sistema de
archivos, I/O y asignación de memoria .
Algo importante a tener en cuenta es que
ésta capa y sus interfaces están construi-
das en C, por lo que usarlas nos puede
agregar complejidad extra.
Core Services. Ofrece los principales ser-
vicios que todas las aplicaciones utilizan
de manera directa o indirecta. Esta capa
es muy importante debido a que en ella
encontramos los servicios de Acceso a
Datos con SQLite, Seguridad, conexiones
www.sg.com.mx
HTTP-FTP y soporte XML. Los frameworks
mas importantes que la componen son
los siguientes:
Core Foundation. Brinda soporte para colec-
ciones de datos, cadenas, bundles, manipu-
lación de URL y streams, soporte multi hilos
y conexiones por puerto y socket.
CFNetwork. Construido en C, nos provee de ma-
nera simplificada el uso de conexiones HTTP-
FTP, además de la resolución de Host DNS.
Core Location. Una de las principales carac-
terísticas de iPhone es la capacidad de saber
en qué longitud y latitud del mundo nos en-
contramos. A través de este framework po-
demos averiguar esta información.
Media
Si tienes en mente un video juego o una apli-
cación con contenidos, ésta es la capa que
www.sg.com.mx
más te interesa. Permite crear aplicaciones
visualmente atractivas con pintado en 2D o
3D, animaciones, audio y video. Todo esto a
través de los siguientes frameworks:
Core Graphics. Contiene las interfaces de dibujo
de Quartz 2D. Este motor de dibujo en vectores
que también podemos encontrar en Mac OS
X provee soporte para degradados, colores y
transformaciones de coordenadas. Sin embar-
go, una de sus características más atractivas es
la creación y visualización de documentos PDF.
Quartz Core. También conocido como Core
Animation. Como su nombre lo dice, expone
las interfaces necesarias para el manejo de
animaciones dentro de la aplicación.
Open GL ES. Framework con interfaces en
C. Provee todo lo necesario para trabajar
objetos en 2D y 3D con alto desempeño ya
que tiene una fuerte integración con el hard-
ware del dispositivo. Seguramente tu mejor
opción al construir un video juego o gráficas
vistosas para el análisis de datos.
Core Audio. Entre sus funciones princi-
pales se encuentran el grabado, mezcla y
reproducción de archivos de audio. En él
también se exponen las interfaces de vi-
bración del dispositivo.
Media Player. Presenta el soporte para visua-
lización de videos a pantalla completa. Entre
los formatos soportados están mov y mp4.
Cocoa Touch
Es la principal capa para la construcción
de aplicaciones, ya que provee la infraes-
tructura necesaria para manejar desde la
interacción del usuario y las vistas, hasta
la internacionalización de nuestra aplica-
ción. Principalmente se compone de dos
frameworks:
MAY-JUL 2009 31
 UIKit Framework. Principalmente utilizado
para el manejo de la aplicación, ventanas y
eventos del usuario. También a través de él
se interactúa con el acelerómetro y la cáma-
ra. Este framework es el más utilizado por
todas las aplicaciones de iPhone.
Foundation Framework. Encapsulando la
funcionalidad expuesta por el Core Fra-
mework del cual hablábamos anteriormen-
te, nos brinda de una manera más sencilla
de manejar arreglos, cadenas, fechas, e in-
ternacionalización entre otras.
Las Herramientas
El iPhone SDK nos provee de distintas aplica-
ciones para llevar a cabo nuestra construcción.
Cada una tiene su funcionalidad específica y
por lo tanto una curva de aprendizaje propia. Al
migrar de otros IDEs como Visual Studio donde
toda la funcionalidad está integrada bajo una
misma interfaz de usuario, podemos sentirnos
incómodos por utilizar varias herramientas a la
vez, pero posteriormente con el trabajo conti-
nuo apreciaremos esta segmentación.
Xcode
Amigable y poderoso, este IDE nos permite
administrar nuestro proyecto y los archivos
que lo componen, compilarlos para ejecu-
ción y depurarlos ya sea en el simulador o en
un dispositivo.
Xcode cuenta con un editor de texto con “code
completion” el cual ofrece una funcionalidad
similar al Intelisense de Visual Studio. Por otro
lado, la capacidad de “code folding” nos per-
mite ocultar lineas de código, por ejemplo mé-
todos terminados o que no serán trabajados
en ese momento. Esto además de las carac-
terísticas usuales como son “sintax coloring”
y la visualización de errores o alertas dentro
de nuestro código. Sin embargo también nos
ofrece la oportunidad de trabajar con nuestro
editor de texto preferido al integrarse de una
manera bastante funcional.
Cuanto trabajamos en equipo también es im-
portante contar con un control de versiones.
Entre los soportados por Xcode se encuen-
tran Subversion y CVS. Pero si eres fanático
de Git encontraras varios Scripts y recetas
creadas por la comunidad para poder traba-
jar con este repositorio de código fuente.
Para aprender a utilizar Xcode a profundi-
dad, te recomiendo visitar su sitio dentro
Juan José Karam es un ingeniero de software multidiciplinario enfocado en la arquitectura y
desarrollo de alta tecnología para emLink. Es expositor en la comunidad CocoaHeads México
(cocoaheads.org.mx) y devoto practicante de Scrum. juan.karam@thesharpcode.com
32 MAY-JUL 2009
del Apple Developer Connection (developer.
apple.com/tools/xcode). Ahí encontrarás
desde cómo realizar la depuración hasta la
automatización de tareas de desarrollo.
Interface Builder (IB)
Interface Builder nos permite diseñar la inter-
faz gráfica de nuestra aplicación partiendo
de componentes precompilados (controles),
manejar sus configuraciones particulares y
la manera en que interactúan con nuestro
código. Es de suma importancia documen-
tarnos correctamente acerca de un control a
ser utilizado, debido a que algunos de ellos
pueden requerir una implementación espe-
cial, como por ejemplo responder llamadas
de algún delegado.
Al referirnos a Interfaz Gráfica, por ejemplo
en Visual Studio con los Windows Forms po-
demos encontrar que son archivos de código
donde se declaran todos los controles que la
componen, así como otras propiedades de la
misma. Sin embargo al hacer la misma refe-
rencia cuando desarrollamos en iPhone en-
contramos un grupo de archivos de extensión
“xib”, los cuales son archivos de recursos en
formato XML generados por una herramienta
de diseño de interfaces, Interface Builder.
Un buen lugar para empezar es la Guia de
Usuario de Interface Builder, disponible
también en el sitio web de Apple Developer
Connection. En ella se explican a detalle las
tareas más comunes cuando construimos in-
terfaces y las conectamos a nuestro código.
Figura. 2. El Interface Builder
Instruments
Partiendo del punto en el que nuestra apli-
cación se ejecutara en un dispositivo móvil
con recursos limitados, ésta deberá estar
construida para optimizar recursos, sobre
todo en la asignación de memoria. Aquí es
donde entra Instruments. Esta herramienta
nos permitirá medir a detalle el manejo de
memoria, uso de disco, conexión a la red y el
rendimiento del motor gráfico.
Recabando los datos ya sea del dispositivo o
del simulador nos presentará una serie de lí-
neas de tiempo donde podremos agregar los
medidores que hagan sentido para evaluar
todos los aspectos del comportamiento de
la aplicación y a su vez nos facilitará la com-
paración y análisis entre ellos. Una de sus
principales características será la capacidad
de grabar lo ejecutado en nuestra interfaz
gráfica, permitiendo reproducirlo las veces
que sea necesario para analizar los distintos
resultados arrojados.
Como se podrán imaginar, la guía de usuario
de Instruments también se encuentra dispo-
nible en el Apple Developer Connection.
¿Donde empiezo?
A mi punto de vista uno de los mejores lugares
para empezar es el iPhone Development Quick
Start (tinyurl.com/dm4hrc). Éste es un tutorial
muy completo y fácil de seguir donde paso a
paso irás construyendo aplicaciones en base a
lo que hemos leído en este artículo.
Consejos Finales
Identifica cual dispositivo es tu objetivo, ya
que en base a eso deberás basar tus caracte-
rísticas. Como un buen ejemplo, el uso de la
cámara únicamente será posible en un iPho-
ne y no en un iPod Touch.
Respeta el manejo de la memoria del dispo-
sitivo, así evitaras que tu aplicación se cierre
en la visualización de un documento impor-
tante o justo en el momento en el que tienes
toda la atención del usuario.
Toma en cuenta siempre la experiencia del
usuario por que ellos sí lo toman en cuenta.
Usa los recursos del dispositivo de forma
conservadora. A ningún usuario le gustará
que la batería del dispositivo se agote rápi-
damente al utilizar tu aplicación.
La documentación que acompaña al
iPhone SDK es tu mejor aliada en
este proceso ya que es fácil de
entender y muy completa.
www.sg.com.mx
Tomando ventaja de la transformación del mercado
por Carlos Silva
Las empresas en México han encontrado en
los desarrolladores de software locales solu-
ciones de calidad mundial. El desarrollo de
aplicativos hechos a la medida de las empre-
sas ha sido un mercado de alta rentabilidad
y crecimiento para los desarrolladores que
han incursionado en este segmento.
Sin embargo, los éxitos en esta primera ola
de adopción de la movilidad no deben ser
motivo para olvidar que este mercado apenas
está naciendo, lo que significa que aún hay
segmentos de clientes por atender y la forma
como las empresas entren a nuevos merca-
dos puede alterar su posición de liderazgo
o relativo retraso en la industria. Por ello, es
necesario atender dos puntos críticos que me
parece influirán de forma contundente en la
definición del futuro mercado móvil.
La necesidad de diferenciarse
Puedo citar al menos cuatro estudios de
prestigiadas casas de investigación de mer-
cados IT que citan que después del correo
electrónico y las listas de contactos, las
aplicaciones móviles más demandadas son
aquellas que automatizan la labor del perso-
nal de campo de ventas y servicio.
Estas aplicaciones para ventas y servicio (llá-
menle Mobile CRM, Sales Force Automation
o Field Service Automation) o supervisión
(merchandising, cobranza) han constituido
la oportunidad más inmediata y rentable
para las empresas dedicadas a la movilidad.
Desafortunadamente, el mercado para
esas aplicaciones ya comienza a mostrar
signos de saturación. Prácticamente toda
empresa establecida o que inicia su estra-
tegia de penetrar el mercado móvil tiene
alguna variante de alguna aplicación de
“toma de pedidos” o “supervisión”. De la
misma forma como en el mercado de apli-
Carlos Silva es Gerente de Alianzas de Research In Motion, fabricante de los dispositivos BlackBerry. Puede ser contactado en csilva@rim.com y vía su
blog personal www.csilva.net. Las opiniones expresada son suyas y no necesariamente reflejan las de RIM.
www.sg.com.mx
caciones de automatización para la peque-
ña y mediana empresa está concentrado
en dos empresas (Aspel y Contpaq), es de
esperarse que en el largo plazo algo simi-
lar ocurra en el mercado móvil.
¿Qué estrategias seguir ante esta expectati-
va? Yo sugiero dos alternativas:
1. Enfocar los esfuerzos en desarrollar pro-
ductos terminados. Muchas empresas en el
mercado cuentan con algún motor básico de
conectividad móvil y GPS que permite ofre-
cer “al cliente lo que pida”. Si bien esta es la
estrategia correcta en un mercado inmadu-
ro, no es una forma escalable de sobrevivir
en un mercado que tenderá a consolidarse.
Generar productos con funcionalidades que
resuelvan las necesidades de la gran mayo-
ría de los clientes con alto grado de confi-
guración y ciclos cortos de implementación
permitirá generar las economías de escala
en la comercialización y despliegue que de-
berán tener las empresas líderes.
2. Enfocarse en segmentos verticales que no
han sido atendidos. Las necesidades de las
industrias de construcción, manufactura es-
pecializada, extracción y servicios profesio-
nales, entre muchas otras, siempre ofrecerán
oportunidades para la especialización a las
que difícilmente podrán acceder los provee-
dores que ofrecen aplicaciones genéricas.
La masificación de las
aplicaciones móviles
El consumo hecho por individuos constitu-
ye dos terceras partes de la economía; más
del 95% de las más de 80 millones de líneas
telefónicas móviles del país son contratadas
por personas (no empresas). Con todo y lo
anterior, los desarrolladores mexicanos ma-
yoritariamente se han enfocado exclusiva-
mente al segmento de negocios.
De nuevo, esta estrategia ha sido la correcta,
pero la apertura de las tiendas de aplicacio-
nes de los principales fabricantes de telé-
fonos inteligentes, de la mano de las estra-
tegias ya desplegadas por los operadores,
representarán una gran oportunidad para
acceder a un mercado enorme.
Recomiendo revisar estas consideracio-
nes a toda empresa de desarrollo que
esté planeando una estrategia de pene-
tración del mercado de consumo:
1. El operador celular manda. Puede no gus-
tar y sonar políticamente incorrecto, pero es
una realidad que en la comercialización de
todo bien o servicio de consumo, el control
lo tiene el detallista. En este caso es el ope-
rador celular (incluso tienen control sobre
las iniciativas de tiendas de aplicaciones de
los fabricantes de dispositivos). Se puede
discutir sobre si los márgenes que para sí
demandan los operadores celulares mexi-
canos son excesivos respecto a prácticas de
otras regiones del mundo, pero la realidad
es que la manera más fácil de que una em-
presa de desarrollo lleve su producto a una
audiencia masiva es hacerlo de la mano del
operador celular.
2. El mercado de consumo es de alto volu-
men y bajos márgenes. Tanto en la definición
de precios como en el cálculo de puntos de
equilibrio se debe tener en mente vender
la mayor cantidad posible que genere una
utilidad total neta aceptable aún cuando el
margen unitario sea relativamente pequeño.
No hay una sola estrategia exitosa para el
mercado de aplicaciones móviles, pero es un
hecho que las empresas que incorporen en
sus planes de negocio los cambios inevita-
bles que experimenta la industria, tendrán
más posibilidades de éxito.
MAY-JUL 2009 33
 // PRÁCTICAS /*CASO DE ESTUDIO*/
Diseño de la Interfaz de SG Guía
Detrás de las cámaras:
Por Romeo Márquez
A inicios del 2009 el staff de SG nos presentó la posibilidad de realizar
el diseño de interfaz para su nuevo proyecto: SG Guía, una herramien-
ta para ayudar a los profesionistas de TI a encontrar los productos y
servicios relacionados con el desarrollo de software. El proyecto nos
pareció muy interesante y a la vez vimos una buena oportunidad de
documentar el proceso para compartirlo con los lectores de SG.
Nuestra colaboración en este proyecto consistió en desarrollar la
arquitectura de información así como el diseño gráfico de la inter-
faz, mientras que la implementación en la herramienta de admi-
nistración de contenido fue realizadas por el equipo de SG. Dicho
sea de paso, las oficinas de SG se encuentran en la Ciudad de México
y gelattina está basada en Monterrey, por lo que trabajar a distancia
solamente hizo el proyecto aun más atractivo!
SG Guía ya se encuentra disponible en www.sg.com.mx/guia por si quie-
res echarle un vistazo para que puedas entender mejor este artículo.
La pre-producción
Notamos una gran ventaja de trabajar con el equipo de SG puesto
que tienen muy buenas prácticas de documentación de requerimien-
tos. Para el análisis inicial SG nos proporcionó documentación con
su visión del proyecto, un modelo de dominio, detalle de actores y
casos de uso del sitio.
Toda esa información es muy valiosa pues en todo proyecto de di-
seño de interfaz, es sumamente importante entender quien será el
usuario final de la aplicación, para así, poder lograr satisfacer sus
necesidades en términos de usabilidad.
Para este proyecto, los dos públicos principales son:
1) Profesionales de IT en busca de servicios
2) Proveedores buscando promover sus productos
Otro aspecto clave tiene que ver con el conocimiento del sistema de
administración de contenido. Es importante tomar en cuenta la plata-
forma de desarrollo para diseñar la interfaz de acuerdo a los reque-
rimientos técnicos. Para este proyecto se seleccionó Drupal (www.
drupal.org) y es parte de nuestra responsabilidad conocer las mejores
prácticas de diseño para dicha plataforma.
Para crear una interfaz de usuario eficiente
1. Brief Creativo
Este documento nos ayuda a definir las necesidades del negocio y los
resultados deseados del diseño. El brief también ayuda a recabar la
información relacionada con la identidad corporativa de la compañía,
tecnologías a utilizar en el proyecto, listar requerimientos estéticos,
proyectos competidores y dar un panorama general de los contenidos a
publicar. SG fue muy específico en sus requerimientos por lo que desde
un inicio, quedó muy clara la expectativa que teníamos que cumplir.
34 MAY-JUL 2009
2. Arquitectura de información
Durante esta etapa, el arquitecto de información clasifica el contenido
y busca crear un menú de navegación optimizado. El resultado que se
obtiene es el mapa del sitio que será clave para la etapa de diseño.
En esta etapa es bueno realizar un benchmark entre proyectos
similares para aprender e identificar los elementos que mejor
puedan servirnos.
Un menú de navegación bien planeado es crítico para lograr una
buena usabilidad ya que el usuario final no debe pensar demasiado
para identificar donde podría estar la información que busca.
La SGuía originalmente contemplaba que las 4 categorías principales fue-
ran parte de la opción del menú “Categorías”. En el interés de facilitar la
navegación al usuario, se optó por desplegarlas como parte del menú
principal. Además del menú de navegación principal, se plantearon una
serie de elementos que no son propiamente parte de la navegación pero
que sirven como ayuda al usuario, por ejemplo, el listado alfabético de
todas las empresas registradas ubicado en la columna derecha.
Finalmente el arquitecto de información realiza los wireframes (represen-
tación sin elementos gráficos que muestran contenido y comportamiento
de las páginas) de la portada e interiores ya que sirven como herramien-
ta de discusión entre él y los programadores, diseñadores y cliente. Los
wireframes son particularmente útiles durante la etapa de planeación ya
que dejarán claro qué elementos se planean incluir en la interfaz.
3. Diseño gráfico
Las dos etapas anteriores nos dan la suficiente información para que
el diseñador realice la mejor interfaz posible totalmente orientada al
público del sitio. En esta etapa el diseñador realiza también su pro-
pio benchmarking enfocado en buscar las soluciones gráficas que
sirvan mejor al sitio.
Con un mapa de sitio claro, wireframes bien definidos, conocimiento
del perfil del usuario final y una idea clara del contenido, el diseñador
tiene todo lo que necesita para crear la interfaz. Como verás, ¡no es
sólo cuestión de sentarse a diseñar si no existe todo un proceso de
planeación detrás!
Para poder replicar la experiencia del usuario común de la SG
Guía, el equipo gráfico de gelattina diseñó 9 pantallas que mos-
traban el recorrido de un usuario desde la portada del sitio hasta
que encontrara la información de un producto en particular, ya
sea por navegación directa o haciendo uso del buscador.
Durante la sesión de revisión con SG validamos que todos los ele-
mentos propuestos fueran viables técnicamente y que no hubiera
alguna restricción técnica de Drupal para poder implementarlos.
www.sg.com.mx
4. Maquetación
Una vez aprobado el diseño, el equipo de desarrollo pudo entrar en
acción para maquetar las plantillas de acuerdo a los estándares web,
es decir, con XHTML, CSS. Adicionalmente, se integró jQuery al código,
un framework de JavaScript que en este proyecto se utilizó entre otras
cosas, para darle un movimiento específico a los íconos de portada.
5. Integración con Administrador de Contenido
La integración del diseño con Drupal, fue ejecutada por el equipo de
desarrollo de SG y gelattina apoyó proporcionando las plantillas y los
elementos complementarios que la aplicación fue requiriendo.
6. QA & Testing
La fase final previa a la publicación incluye la revisión del diseño buscan-
do asegurar que haya sido integrado correctamente con el administrador
de contenido y que el concepto original se haya respetado al máximo.
Una parte fundamental antes de publicar cualquier sitio es el beta tes-
ting no sólo de la interfaz, sino del proyecto completo para asegurarse
de que no haya enlaces rotos, imágenes y textos fuera de lugar, etc.
Dependiendo del tiempo y el presupuesto, es recomendable hacer usa-
bility testing para refinar la interfaz con la retroalimentación de usuarios
reales, además de hacer una optimización del sitio para buscadores,
aunque ambos temas los dejaremos para futuros artículos.
Romeo Márquez es fundador de gelattina, una agencia especializada en Web 2.0, diseño de interfaces, Marketing Digital, Social Media, Widgets y Video para Web.
Adicionalmente es miembro de la Usability Professionals Association. Para gelattina, ha dirigido proyectos de diseños de interfaces para The Home Depot, Coca-
cola, Banorte, Banregio, JackBe, Hoteles Marriott, ABA Seguros entre otros. Puedes seguirme en Twitter en @RomeoMarquez y @gelattina www.gelattina.com
romeo@gelattina.com +52.81.8115.6150
www.sg.com.mx
La prueba de la cajuela
Durante las etapas de diseño y QA tomamos en cuenta la “prueba de
la cajuela”. Lo que sucede es que solemos pensar que la navegación
de un sitio empieza desde la página principal. Sin embargo, la mayoría
de las veces los buscadores dirigen a los usuarios a partes específicas
en el interior del sitio, por lo que es importante asegurarnos de que el
visitante podrá ubicarse al llegar a cualquiera de nuestras paginas.
La prueba de la cajuela (trunk test) fue creada por Steve Krug y con-
siste en una evaluación sencilla para determinar si un sitio tiene una
buena interfaz sin importar en que pagina se encuentre el usuario.
La idea es esta: imagina que te meten a la cajuela de un carro y te
dan muchas vueltas para desubicarte y al final eres liberado en una
página interior del sitio web a evaluar.
Si la página está bien diseñada deberías ser capaz de responder a estas
preguntas sin dudarlo: 
• ¿Qué sitio es este?
• ¿En que página estoy?
• ¿Cuáles son las secciones principales de este sitio?
• ¿Cuáles son mis opciones en este nivel?
• ¿Dónde estoy?
• ¿Cómo puedo realizar una búsqueda?
Esta prueba sencilla nos ayuda a mantener en mente conceptos esencia-
les para facilitar no solo la navegación si no la interacción del usuario con
nuestro sitio.
Conclusión
La creación de un proyecto web, cualquiera que sea su tama-
ño, que busque ser exitoso requerirá de un buen trabajo de
integración tanto en la parte tecnológica como en la interfaz
del usuario. Para eso se requiere de un equipo multidiscipli-
nario con experiencia en las áreas de usabilidad, arquitectura
de información, diseño gráfico y desarrollo de aplicaciones.
Mientras más se utilice la empatía con el usuario y se combi-
ne el conocimiento de sus hábitos, mayor probabilidad ten-
drá de éxito el proyecto. SG Guía fue creada para cumplir con
las necesidades de los lectores de esta revista, por lo que te
invito a conocer el sitio y utilizarlo. Si tienes algún comen-
tario que pueda mejorarla, lo recibiremos con gusto.
MAY-JUL 2009 35
 // PRÁCTICAS /*MEJORA DE PROCESOS*/

MoProSoft y la Auditoría
a Procesos de Software
El Sistema MADAM Asociado a MoProSoft
Por Yolanda Fernández, Leticia Arévalo, Jesús Soria

Una auditoría de calidad a cualquier tipo de

procesos de una organización se orienta a veri-
ficar cómo se desarrolla una cierta actividad de
acuerdo a una norma establecida. La auditoría
se apoya en una serie de documentos que defi-
nen todos los aspectos a cubrir: qué se requiere
revisar y qué se persigue al hacerlo, quiénes y
de qué manera están involucrados, qué y cómo
se reportan los resultados.

Una auditoría típicamente se organiza en cua-

tro fases, cada una con productos a obtener:
preparación, ejecución, informe y cierre. La
preparación establece los grandes rubros a
auditar; los productos son el plan de auditoría
y el programa. La ejecución realiza la revisión
detallada especificada en el plan, comparan-
do requisitos contra evidencias. Los productos
de esta fase son los datos que sustentarán lo
observado, mismos que se analizarán y cate-
gorizarán en desviaciones de la norma o ha-
llazgos, y eventualmente en buenas prácticas.
El informe de auditoría organiza y documenta
las conclusiones a enviar al auditado. El cierre Figura 1. Fases de Auditoría (adaptada de Arter, 1994)
da por concluida la auditoría con acciones de
recomendación y seguimiento. Ver Figura 1. de acuerdo a cómo se han implantado los La metodología para
procesos. Una consecuencia de la evalua- auditorías de MoProSoft
La auditoría a la calidad ción es sugerir mejoras que permitan al- MoProSoft define documentos que des-
de procesos de software canzar el siguiente nivel de madurez. Hay criben lo que se debe auditar para cada
Si los procesos de interés son los de la ge- una retroalimentación explícita de resulta- uno de los procesos en las tres catego-
neración y mantenimiento de software, la dos en este sentido. rías: Alta Dirección, Gerencia y Opera-
auditoría de calidad se orienta a verificar ción. En cada documento aparece la serie
si la organización cumple con los linea- Por otro lado, la auditoría es una revisión ordenada de acciones y procedimientos
mientos establecidos en un modelo de ca- detallada de cómo se están realizando las para revisar y calificar actividades en
lidad de software específico. cosas y si están cumpliéndose o no los re- cada etapa del proceso. La estructura de
quisitos prescritos en una norma o mode- los documentos puede adaptarse a los li-
Una auditoría es similar a una evaluación, lo, apelando a observaciones directas de neamientos de implantación del modelo
aunque con algunas diferencias. En una agentes externos. El dictamen puede ser de en una organización en particular. En la
evaluación el objetivo primordial es de- cumplimiento de lo establecido en la norma Tabla 1 se resumen los nombres y conte-
terminar un nivel de madurez especificado o de efectividad en el alcance de metas de nidos de los documentos para cada fase
en el modelo de software que se establece calidad determinadas. de la auditoría.

Yolanda M. Fernández Ordóñez profesora investigadora titular del Colegio de Postgraduados, Campus Montecillo. Es Matemática egresada de la Facultad de
Ciencias de la UNAM y Doctora en Informática por el Instituto Nacional Politécnico de Grenoble, Francia. Sus áreas de interés son la ingeniería de software y la
geomática aplicada a las ciencias agrícolas y los recursos naturales. Formó parte del Grupo Editorial que elaboró el MoProSoft. Es miembro del Sistema Nacional
de Investigadores. yfernand@colpos.mx

36 MAY-JUL 2009 www.sg.com.mx

 FASE NOMBRE DOCUMENTO CONTENIDO

Propósito de auditoría Qué se persigue y qué debe calificarse para el

proceso.
Alcance de auditoría Identificar la profundidad de la revisión
Plan de auditoría Actividades específicas que se revisarán
Documentos Aplicables: qué documentos de
la organización se anticipa que contienen la
información a revisar.
Equipo auditor: nombres y firmas de responsa-
Preparación
bles de la ejecución de la auditoría.
Participantes: grupo de la organización
auditada responsable de actividades a revisar.
Firma autorizada de aprobación
Listas de verificación (checklists) del auditor.
Programa de auditoría Calendarización detallada de actividades

Métodos de Cuestionarios
recolección de datos Plantillas de entrevistas
Ejecución Especificación de la revisión documental Figura 2. Carátula Documento Cierre de Auditoría.
Definición de encuestas
Técnicas de muestreo
Matriz de doble entrada Requisitos/Evidencias
Informe de Auditoría Narrativa detallada de hallazgos y ubicación Conclusión
del hallazgo (en qué parte del proceso) La metodología resulta de la aplicación de los principios de
Informe Buenas prácticas* auditoría a la norma MoProSoft. Se siguen las fases prevale-
Resumen General de Narrativa resumida de hallazgos y logros
cientes en las auditorías para revisar los procesos consideran-
Auditoría significativos y métodos utilizados.
Cierre de Auditoría Dictamen formal de la auditoría. do el nivel 1 de capacidades: Proceso Realizado de MoProSoft.
Como anexos: Plan de Auditoría, Listas de Se proponen documentos de apoyo al auditor que identifican
Cierre Verificación llenas, Informe de Auditoría y los aspectos relevantes, como el propósito de la auditoría, su
Plan de Acciones Correctivas*
alcance, los puntos auditables y el informe de cierre. Se men-
Informe de situaciones relevantes*
Plan de Acciones
cionó el sistema asociado MADAM que maneja documentos
Correctivas* adaptables para auditar a una organización.

* Opcional, en su caso.
Tabla 1. Documentos y su contenido por fases de la auditoría
El Sistema MADAM
Para facilitar esta metodología hemos creado el sistema MADAM (Ma-
nejo de Documentos para Auditoría MoProSoft) a través del cual se ma-
nejan y adaptan los documentos para auditar distintas organizaciones.
Los rubros del contenido en las carátulas de los documentos MADAM
son enlaces a los documentos relacionados correspondientes.
En la Figura 2 se muestra la carátula del documento Cierre de Au-
ditoría para el proceso DIR. 1. Gestión de Negocios, donde el audi-
tor debe llenar lo indicado en el Contenido para dar por concluida
la auditoría.
Referencias
[Arevalo-Cedillo, Leticia. “Auditoría y Evaluación de Calidad de Pro-
cesos de Software usando la norma NMX-059/01-NYCE-2005 Mo-
ProSoft”. Tesis de maestría en ciencias, Colegio de Postgraduados,
Montecillo, Texcoco, Edo. De México. 2006.]
[Arter, Dennis. “Quality Audits for Improved Performance.” 2nd Ed.
1994. ASQ Quality Press]
[Oktaba, H.;M. Piattini. “Software Process Improvement for Small
and Medium Enterprises: Techniques and Case Studies.” IGI Global,
Hershey PA. 2008.]
[normalizacion-nyce.org.mx/doc/NMX-I-006/04-NYCE-2004.pdf> ]
[software.net.mx/Evento2008/presentaciones/Mixteca%201/Mo-
ProSoft_sin_fronteras_mayo_2008_evento.pdf]

Leticia Arevalo Cedillo profesora de asignatura y actual Presidenta de Academia del Área de Docencia de Cómputo en la Universidad Autónoma del Estado de México.
Licenciada en Informática Administrativa egresada de la UAEMex y Maestra en Ciencias en Cómputo Aplicado del Colegio de Postgraduados. letyac@colpos.mx

Jesús Soria Ruiz investigador del Instituto Nacional de Investigaciones Forestales, Agrícolas y Pecuarias, encargado del Laboratorio de Geomática del INIFAP
en Toluca. Doctor en Ciencias por el Colegio de Postgraduados. soria.jesus@inifap.gob.mx

www.sg.com.mx MAY-JUL 2009 37

 // PRÁCTICAS /*ASEGURAMIENTO DE CALIDAD*/
Medición y Análisis
¿Qué, Cómo, Cuándo?
Por Edith Alhelí Martínez
A lo largo de la definición e implantación de un programa de mejora, me
he encontrado con temas que nos pueden “parar en seco” al momento de
la ejecución. Uno de eso temas es el de Medición y Análisis cuyo objetivo,
de acuerdo a CMMI es: “Desarrollar y sostener una capacidad de medida
que es usada para apoyar necesidades de información de dirección”.
En general, cuando se llega al punto de definición de este proceso, no
podemos avanzar o empezar a definir sin involucrar a más personal de
la organización.
Lo que sucede frecuentemente es que el Responsable de Proce-
sos (por llamarlo de alguna forma), puede conocer el modelo de
calidad y conocer a la organización, sin embargo en este caso se
necesita considerar más aspectos. Entre estos aspectos están el
de conocer las metas y objetivos de la organización y sus distintas
gerencias, sus prioridades y asegurarse de validar con ellos esta
definición de proceso.
A partir de ahí, ya estamos del otro lado por decirlo de alguna mane-
ra, ahora solo resta identificar qué es más importante, imprescindi-
ble, necesario, o simplemente es un “nice to have”…
Yo empezaría por pensar primero qué nada en: ¿Por qué medir? ¿Para
qué me serviría? ¿Qué quiero medir?, ¿Por qué eso y no algo más? ¿Cuál
es su criticidad?
¿Por qué medir?
Para comprender la situación actual de alguna actividad, para esta-
blecer una línea base inicial, para poder predecir, para mejorar, para
ser eficiente, o para saber cuánto…
Existen indicadores de empresas nacionales e internacionales que
se encuentran difundidos en el mundo, los cuales nos pueden ser-
vir de punto de partida o comparación (benchmarking), sin em-
bargo es importante tener en mente que son eso, indicadores de
otras empresas.
Edith Alhelí Martínez Mata es Consultor especializado en temas de CMMI. Sus áreas de especialidad son el Aseguramiento de la Calidad, las Inspecciones
de Software, los Procesos de Administración de Proyectos y Soporte. Ha participado como consultora en varios proyectos para implementación de CMMI a
diferentes niveles, así como en evaluaciones SCAMPI. Alhelí estudió en el Instituto Tecnológico de Aguascalientes (ITA).
38 MAY-JUL 2009
Estas otras empresas seguramente serán diferentes a la nuestra en
cuanto a su:
• Tamaño
• Cultura
• Productos o Tecnología
• Giro
• Objetivos
Partiendo de eso, entonces no hay mejor punto de comparación que
nuestro propio antes, ahora y después. Es bueno tomar el resto de los
datos como puntos a revisar y comparar contra ellos, pero es importante
saber de antemano que quizá no podremos ni tendremos que llegar a ser
idénticos a ellos.
Algunos puntos a considerar son:
1. Alinear las mediciones a los objetivos de la Organización para
lograr consistencia.
2. Empezar con pocas medidas, pero asegurar su practicidad,
bajo coste y alto beneficio.
3. Hacer una buena y clara definición de métricas, contestando a
las preguntas de ¿qué? ¿cómo? ¿cuándo? ¿dónde? y ¿por qué?
4. Automatizar lo más posible la obtención y análisis de datos y
realizar análisis concretos de los datos.
5. Difundir los resultados de manera simple y entendible, así
como utilizar la medición y sus resultados a favor y no en contra.
6. Recordar la ya sonada frase que dice “lo que no se mide, no se
puede mejorar”.
7. Elegir los modelos y técnicas de medición. ¿Cómo elegir? ¿Peor,
mejor? ¿Pros y contras?… Hay que ajustarse a las necesidades,
características, objetivos y presupuestos de cada empresa.
www.sg.com.mx
 “No hay mejor punto de comparación que
nuestro propio antes, ahora y después”.
8. Comprender que adoptar la práctica de
medición implica un cambio de cultura que
requiere esfuerzo, proactividad, adopción,
seguimiento y actualización. A fin de cuen-
tas, la medición es una tarea de todos y es un
beneficio y logro de muchos.
9. Continuar con el proceso de medición y
mejora. Una vez mejorado x, mejorar y, z y
así sucesivamente.
10. Por último, tener presente lo siguiente
sobre la medición:
• La medición no solo debe dar respuesta a
bien o mal, sino indicar qué tanto.
• Medir cuesta, por supuesto. Por ello es crucial
determinar qué es lo que se va a medir y enfo-
carse en eso.
• Las mediciones ayudan a tomar decisiones
acertadas y precisas.
• La mejora de calidad, tiempos o esfuerzos
no se logra de un día a otro. Es como todo…
toma tiempo.
Figura 1. Gráfica de seguimiento a defectos
www.sg.com.mx
La figura 1 muestra un ejemplo de una grá-
fica para el seguimiento de defectos en una
aplicación de software. Como pueden ver,
en una sola gráfica podemos presentar in-
formación de gran utilidad.
Para cerrar este artículo les comparto una
frase que se atribuye a W. Edwards De-
ming, considerado el padre de la revolu-
ción de la calidad:
“In God we trust, all others bring Good data” (En
Dios confiamos, los demás traigan Buenos datos).
Referencias
[ sei.cmu.edu/sema ]
[ Mary Beth, Mike Konrad. “CMMI(R)
Second Edition, Guidelines for Process
Integration and Product Improvement.” ]
[ Khaled Emam. “Process Improvement in
a Small Company” ]
[ David Card. “Measurement Makes Impro-
vement Meaningful” ]
MAY-JUL 2009 39
 // PRÁCTICAS /*aRQUITECTURA DE SOFTWARE*/
El Valor de los Ciclos Guiados
por la Arquitectura del Software
Poniendo el enfoque en los objetivos de negocios y los atributos de calidad del producto
Por Alejandro Bianchi
Si tuviésemos que precisar un atributo que defina al software en
estos tiempos, seguramente muchos coincidirían en que la comple-
jidad es algo destacable. Esto se manifiesta en el volumen de los
productos, utilización de productos COTS (Comercial off the self ),
la integración a través de diferentes tipos de interfaces, la intero-
perabilidad entre diferentes plataformas y la conjunción de más
de una tecnología para el desarrollo de un mismo producto. Dicha
complejidad también se manifiesta a través de los requerimientos,
tanto en cantidad como en los diferentes tipos y prioridades de las
necesidades expresadas por las distintas personas interesadas por
el producto bajo desarrollo.
Muchos de estos requerimientos están expresando atributos que el
software debe satisfacer para asegurar una adecuada calidad: desem-
peño, seguridad, mantenibilidad, etcétera. Estos atributos, reconoci-
dos como “requerimientos no funcionales” o “atributos de calidad”
son a veces la causa de importantes desvíos en el desarrollo o de se-
rios problemas en la operación del producto, provocando insatisfac-
ción de los usuarios y frustración de los equipos de desarrollo.
Por otro lado si analizamos el problema desde la óptica de gestión
de proyectos, la situación nos presenta un escenario también com-
plejo: múltiples equipos trabajando en diferentes lugares con dife-
rentes culturas, así como diferentes proveedores interactuando con
complejas relaciones de trabajo y fuertes restricciones de tiempo y
presupuesto. Si bien es cierto que la utilización de modelos de cali-
dad ha contribuido en gran medida a mejorar la capacidad de produ-
cir software en las organizaciones, esas mejoras en la práctica se han
concentrado en aspectos vinculados con la gestión de los proyectos
y con menor énfasis en la mejora de la ingeniería de los productos,
aun en niveles avanzados de madurez.
Esta falta de foco en la ingeniería podría atribuirse a una mala in-
terpretación de los modelos o a la minimización del impacto de los
métodos en la calidad del producto. Dado el escenario que hemos
planteado al inicio, se hace imprescindible que los procesos de de-
sarrollo comiencen a enfocarse en las prácticas que mejor resuelvan
la complejidad de los productos para asegurar que, además de la
funcionalidad, se satisfacen adecuadamente los atributos de calidad
que el software debe proveer.
Estas prácticas de ingeniería adecuadamente integradas con las
prácticas de gestión conforman procesos eficientes, eficaces y por
sobre todo proactivos. En este artículo presentamos una visión que
apunta a proveer una solución centrada en el diseño de la arquitec-
tura como conductor del proceso de desarrollo, garantizando la ca-
lidad del producto y proactividad en todas y cada una de las etapas
de fabricación e implantación.
40 MAY-JUL 2009
Una definición de arquitectura de software
La arquitectura de un producto complejo de software es uno de
los artefactos más importante del ciclo de desarrollo. Si bien sus
principios y resultados han sido analizados, definidos y divulga-
dos por un periodo de diez años, su práctica formal por parte de la
comunidad profesional, es todavía vaga e imprecisa. Existen mu-
chas definiciones de arquitectura de software, nosotros creemos
que una que sintetiza la esencia de la misma es la elaborada por
Clemens, Bass y Kazman[1]: “La arquitectura de un programa o sis-
tema es la estructura o las estructuras del sistema que contienen a
los componentes, las propiedades visibles de estos componentes
y las relaciones entre ellas.”
De esta definición podemos deducir:
1. La arquitectura es una solución de alto nivel que muestra de qué
manera serán resueltos los objetivos de negocio que dan origen al
producto. En este sentido podemos decir que la arquitectura del soft-
ware es “un puente” entre las necesidades de los usuarios y los equi-
pos técnicos que serán responsables del desarrollo.
2. La arquitectura solo se ocupa de mostrar y resolver las propiedades
visibles de los elementos, (mencionados como atributos de calidad).
No interesan los detalles internos de cada uno de ellos.
3. La arquitectura muestra las grandes decisiones de diseño y su jus-
tificación, facilitando de esta manera la comprensión por parte de
los grupos técnicos.
4. La arquitectura facilita la comunicación entre los diferentes involu-
crados (stakeholders) en el desarrollo del producto.
5. La arquitectura es la base para facilitar el reuso a diferentes nive-
les de abstracción.
6. Las revisiones de arquitectura son, junto con la validación de los
requerimientos, la primera actividad proactiva de calidad, la cual
permite detectar conflictos técnicos y/o defectos en la estructura del
producto, reduciendo de esta manera el retrabajo en etapas poste-
riores del desarrollo.
Por último, la documentación de la arquitectura de software es
el artefacto más importante que sintetiza el conocimiento acer-
ca del producto. Ésta no solo contribuye significativamente en
el diseño de la estrategia del proyecto (ciclo de vida) sino que
también será esencial en el periodo de evolución del producto, y
será de gran utilidad como medio de aprendizaje para el equipo
de desarrollo.
Sin entrar en detalles, términos como arquitectura de referencia,
patrones de diseño, frameworks de arquitectura, le dan cuerpo a la
definición que hemos dado. En los ciclos de vida clásicos el diseño
de arquitectura, por lo general, no está adecuadamente formaliza-
do. Muchas veces resulta común confundir diseño de detalle con
www.sg.com.mx
 “La arquitectura de un producto complejo
de software es uno de los artefactos más
importantes del ciclo de desarrollo”.
arquitectura. Los requerimientos no funcionales son poco conside-
rados en los requerimientos del producto y por consecuencia no
incluidos en la definición de la solución, lo que repercute en las
tareas de construcción y testing incrementando los defectos y el re
trabajo. En el resto de este trabajo presentamos algunas ideas para
utilizar de manera eficiente los conceptos de arquitectura de soft-
ware a partir de incorporar el proceso de diseño como componente
esencial del ciclo de desarrollo.
Qué es un ciclo de vida guiado por la arquitectura
Si bien no hay una definición consensada sobre lo que es un ciclo
de vida guiado por la arquitectura, podemos decir que es un ciclo
en donde los objetivos de negocios y los atributos de calidad del
producto conducen el diseño de la arquitectura, y ésta es la base
para la definición del resto del ciclo de producción y evolución a
partir de:
• Definir la estructura del proyecto (ciclos de vida, estimaciones, con-
formación de equipos, plan de comunicación, estrategia de configu-
ration management, plan de pruebas, estrategia de integración e im-
plantación del producto).
• Definir la estrategia de integración entre proveedores.
• Definir los mecanismos de coordinación entre grupos ubicados en
diferentes locaciones.
• Definir la estrategia de transferencia de conocimiento a grupos de
mantenimiento.
La figura 1, adaptada de Paulish[2], muestra un modelo de ciclo de vida
guiado por arquitecturas:
Figura 1. Modelo de ciclo de vida guiado por arquitecturas
www.sg.com.mx
Lo más destacable de esta figura se puede sintetizar en los si-
guientes puntos:
1. Los requerimientos analizan la funcionalidad y también defi-
nen, en base a los objetivos de negocios los atributos de calidad
que el producto debe satisfacer.
2. Un análisis global toma los requerimientos y las restricciones del
proyecto e identifica los factores que dirigen el desarrollo (drivers),
que sirve de entrada al diseño de arquitectura.
3. El diseño de la arquitectura utiliza estos factores identifica-
dos y aplicando patrones y tácticas elabora la solución técnica
del producto, la cual se sintetiza en un documento de arquitec-
tura, que contiene n vistas en donde cada una de ellas refleja
los intereses de cada uno de los stakeholders del producto. Por
ejemplo, vista funcional, de información, de desarrollo, de des-
pliegue y de operación. Otro ejemplo se puede encontrar en el
modelo 4+1 elaborado por Phillip Kruchten[3] .
4. El producto del diseño de arquitectura es revisado para detectar
conflictos entre atributos de calidad, aspectos no cubiertos por el
diseño, riegos técnicos y decisiones no formalizadas que puedan
atentar contra la comprensión del producto.
5. El diseño de arquitectura ajustado es utilizado para definir la
estrategia de fabricación e implantación del producto. Esta estra-
tegia se plasmará en un ciclo de vida o una combinación de ciclos,
la cual se ve en el Plan de proyecto que gestionará la producción
del producto.
6. Todo este marco de trabajo está soportado por un proceso integral
de gestión de la configuración y de aseguramiento de la calidad.
Desde el punto de vista de los modelos de calidad, específicamente
el CMMI-DEV, el diseño de arquitectura es una entrada importante
al procedimiento de configuración que exige IPM, (Integrated Pro-
ject Management). Por lo general, IPM es vista como la “tijera” que
permite eliminar “lo que se necesita del proceso”. Pero si interpre-
tamos esta práctica vamos a concluir que es mucho más que eso:
esta área facilita la definición del mejor proceso que el proyecto
necesita a partir de contar con una estrategia adecuada al mismo.
Cuando tenemos esta interpretación clara le sacaremos más valor
a IPM. El diseño de arquitectura ayuda a definir esta estrategia y
plasmarla en el proceso definido para el proyecto.
Métodos prácticos para aplicar a un ciclo
guiado por arquitecturas.
El Software Engineering Institute (SEI) viene trabajando desde hace
más de diez años en la definición de métodos para soportar los ci-
clos de vida guiados por la arquitectura. Son métodos prácticos que
se sustentan en el uso de escenarios. Un escenario es una instancia
concreta del uso del sistema y se compone de estimulo, elemento
MAY-JUL 2009 41
 // PRÁCTICAS /*aRQUITECTURA DE SOFTWARE*/
estimulado, resultado esperado en base a mediciones y el ambiente
en donde el escenario se produce.
La tabla 1 muestra los métodos, los roles involucrados y qué etapa
del ciclo de vida soportan:
Tabla 1. Métodos, roles involucrados y etapa del ciclo de vida
QAW es un taller (workshop) en donde se integran los diferentes in-
volucrados para identificar los atributos de calidad que serán drivers
del diseño de arquitectura del producto. QAW facilita la resolución
temprana de conflictos, obtiene consensos entre los stakeholders y
ayuda a mejorar los requerimientos a todos los niveles.
ADD es un método iterativo para diseñar la arquitectura del producto
en base a los drivers definidos en el QAW. ADD aplica patrones y tác-
ticas de diseño que apuntan a asegurar que los atributos de calidad
estarán presentes en el producto.
ATAM es un método altamente estructurado para evaluar un diseño
de arquitectura. ATAM permite detectar, de manera temprana, ries-
gos técnicos, conflictos entre atributos, puntos sensitivos del diseño
y soluciones.
Alejandro Bianchi es analista de sistemas, con un curso de postgrado en Sistemas Expertos de la Universidad Católica de La Plata y un diploma en Gerencia
Estratégica de la Universidad Argentina de la Empresa. Socio y presidente de LIVEWARE Ingeniería de Software. Consultor internacional, con más de veintiséis
años de experiencia en desarrollo de software, consultoría y administración de tecnología informática.
42 MAY-JUL 2009
La documentación mediante vistas es una forma de documentar el
diseño de arquitectura considerando los intereses de los interesados
en el producto. Existen variadas maneras de expresar las vistas y sus
interrelaciones. Esta es una lista de las potenciales vistas.
• Funcional. Describe los elementos funcionales del producto, sus
responsabilidades, interfaces e interacciones primarias. Esta vista es
la que conduce al resto.
• Información. Describe la manera en que la arquitectura alma-
cena, manipula, maneja y distribuye información. Describe una
visión estática y dinámica de la infromación dentro del producto.
• Concurrencia. Describe las estructuras de concurrencia del sis-
tema y mapas funcionales para identificar unidades de concurren-
cia que puedan ser ejecutadas en forma simultanea y la manera en
como estas son coordinadas y controladas.
• Desarrollo. Describe la arquitectura que soporta el desarrollo del
producto. Representa cuestiones de interés para las personas involu-
cradas en construir, probar, mantener y evolucionar el producto.
• Deployment. Describe el ambiente en el cual el sistema será implan-
tado, incluyendo las dependencias que el sistema tiene en tiempos de
ejecución. Mapea cada elemento de software a otros componentes ne-
cesarios para que la ejecución esté de acuerdo a los requerimientos.
• Operación. Describe la manera en cómo el sistema será operado,
administrado y soportado en tiempo de operación productiva.
Los métodos se potencian utilizando herramientas de modelado y de
soporte a la documentación de la arquitectura tales como Enterprise
Architect, o Rational Architect o por ejemplo. Incluso un wiki puede
integrar un repositorio integral de la arquitectura.
Referencias
[1. Bass; Clements & Kazman. “Software Architecture in Practice”.
1998]
[2. Paulish, Danie. “Architecture-Centric Software Project Management”.
2002]
[3. Krutchen, P. “The 4+1 View Model of Architecture”.IEEE Soft-
ware, Vol 12, nro. 6, 1995]
[sei.cmu.edu/architecture/index.html]
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009 43
 // PRÁCTICAS
Programación Declarativa
Conociéndola y entendiendo su aplicación real
Por Gastón Milano
Si al escribir un programa de cómputo lo que hacemos es explicarle a
la computadora por medio de instrucciones detalladas “cómo hay que
realizar una tarea”, entonces estamos programando en forma impera-
tiva. Es decir, estamos alimentando los pasos o conjunto de instruc-
ciones necesarias para resolver un problema. Por otro lado, si al escri-
bir un programa estamos describiendo “qué hay que hacer”, entonces
estamos programando en forma declarativa. Es decir, describimos el
problema que queremos solucionar, pero no las instrucciones necesa-
rias para resolverlo. La programación declarativa es tan solo eso.
En realidad, la programación declarativa es un término que agru-
pa los siguientes paradigmas de programación:
Programación lógica. Los problemas se representan por medio de
lógica matemática.
Programación funcional. Todo se resuelve por medio de la evalua-
ción de funciones matemáticas.
Lenguajes de dominio específico (DSLs). Lenguajes descriptivos
para un propósito específico, tales como HTML, CSS y SQL.
Lenguajes híbridos. Un ejemplo son los archivos “make” que com-
binan la descripción de dependencias entre componentes, con ins-
trucciones imperativas para compilar o instalar una aplicación.
Ventajas de la programación declarativa
Cuando pensamos en los beneficios de programar en forma de-
clarativa, en general se empieza pensando en las ventajas pro-
pias del lenguaje a utilizar. Por ejemplo, si se está usando un
lenguaje funcional, la principal ventaja es que al lidiar puramente
con funciones, no necesitamos preocuparnos por el estado de la
información, ya que los datos sean inmutables. Por otro lado, en
el caso de los lenguajes basado en reglas, los programas son más
claros y entendibles incluso por los usuarios.
A pesar de todo esto, la ventaja más importante de la progra-
mación declarativa consiste en que el indicar a la computadora
Gastón Milano es un ingeniero uruguayo quien ha trabajado durante muchos años en el desarrollo de software utilizando lenguajes declarativos. Actualmente
es Arquitecto de Software de Genexus una herramienta de generación de aplicaciones partiendo de conocimiento declarado.
44 MAY-JUL 2009
/*PROGRAMACIÓN*/
“qué” tarea es la que tiene que hacer, en lugar de “cómo” hacerla
nos protege de cambios en el contexto tecnológico. En ese senti-
do, el qué perdura mucho más que el cómo.
Un primer ejemplo
Veamos un ejemplo de cómo nos puede ayudar la programación
declarativa. Supongamos un caso sencillo de un programa que
suma los números del 1 al 100. Una posible solución procedural
podría ser un programa similar al siguiente:
int suma = 0;
for (int i = 1 to 100)
suma += i;
return suma;
Una solución declarativa podría ser simplemente:
suma = Sum(1, 100)
Dado este ejemplo sencillo, lo primero que uno advierte es que
se necesita un lenguaje de más alto nivel que dé soporte a las co-
sas que declaramos: en este caso alguien tiene que implementar
el Sum, y el programador no tiene idea cómo se está resolviendo
el proceso de la suma.
Hoy, luego de mucho tiempo, estamos frente al fenómeno de que
la mejora en desempeño para una máquina no se da simplemente
cambiando el procesador, sino que necesitamos sumar más pro-
cesadores. Ya muchas computadoras están equipadas con tecno-
logía de cuádruple núcleo.
Aquellos programas como el que hace la suma imperativamen-
te, deberá decir explícitamente (por ejemplo mediante el uso de
threads) que necesita hacer uso de los nuevos procesadores. Sin
embargo, el programa declarativo no cambia, será exactamente
igual y la implementación de cómo se hace la suma es un tema
de capas tecnológicas de más bajo nivel. Como desarrollador de
aplicaciones de negocio, no quiero perder el foco de lo que quiero
hacer y perderme en temas tales como threading, serialización y
sincronización.
www.sg.com.mx
 “... indicar qué es lo que se debe hacer en lugar
de cómo hacerlo nos protege de cambios en el
contexto tecnológico”.

Lenguajes declarativos
Existen una gran cantidad de lenguajes declarativos. En el caso
de los funcionales, entre los más populares están Scheme, Er-
lang, y otros más nuevos como F#. para cierto dominio específico.
Los lenguajes de dominio específico comunmente son utilizados
para declarar formulario, por ejemplo HTML, XAML, XUL e incluso
las hojas de cálculo.
En Artech, la empresa donde laboro, tenemos un producto llamado
GeneXus que permite crear aplicaciones de negocio utilizando progra-
mación declarativa. La herramienta utiliza lenguajes declarativos para
el modelado de las entidades de negocio, la declaración de reglas de
negocio, la especificación de formularios, y la exposición de datos.
Conclusión
Ahora, después de 20 años, los grandes de la industria
comienzan a darse cuenta de los beneficios de programar
en forma declarativa. Antes de su retiro de Microsoft, el
propio Bill Gates aconsejó que “deberíamos estar hacien-
do las cosas en forma declarativa (…) no deberíamos estar
escribiendo tanto código procedural”. Si queremos lograr
un verdadero incremento de productividad, es importante
que todos dentro de la comunidad del desarrollo de soft-
ware nos demos cuenta que claramente debe existir un
cambio de paradigma a la hora de programar.

www.sg.com.mx MAY-JUL 2009 45

 // PM CORNER
Revisión de la 4ta edición de la Guía PMBOK
Cambios Importantes
Por Jorge Valdés
El pasado 31 de diciembre de 2008, el Project Management Insti-
tute (PMI), publicó de manera simultánea la actualización de cua-
tro de sus estándares fundamentales. De ellos, el más importante
y difundido es por mucho La Guía PMBOK.
La actualización de los estándares del PMI
Los estándares reflejan prácticas comunes y un lenguaje univer-
sal para la profesión. Esto resulta en una mejor entrega de pro-
yectos, incrementos en el retorno de la inversión y por supuesto,
cuando son adoptados correctamente, una empresa más compe-
titiva por el incremento en su productividad.
El pasado 31 de diciembre el PMI liberó actualizaciones a sus cuatro
estándares fundamentales. Estos estándares representan las cuatro
disciplinas clave en la profesión de dirección de proyectos:
• A Guide to the Project Management Body of Knowledge
• The Standard for Program Management
• The Standard for Portfolio Management
• Organizational Project Management Maturity Model (OPM3)
Con la liberación simultánea de las nuevas versiones, el PMI bus-
ca alinear estos estándares fundamentales. Esto ayuda a asegu-
rar que los profesionales de esta disciplina hablen el mismo idio-
ma, incrementando el entendimiento.
Con ello, el PMI inició el proceso de armonización, incluyendo la eva-
luación de inconsistencias a lo largo de los cuatro estándares. Al final
de lo que fue un largo y complicado proceso de revisión, los equipos
participantes lograron estándares que no sólo están alineados sino
que presentan la información de una forma clara y consistente.
Los cambios en la 4ta. edición de la Guía PMBOK
La Guía PMBOK 4ta. edición se enfoca en la ejecución de un solo
proyecto a través de los distintos grupos de procesos y establece
una relación cruzada con las áreas de conocimiento.
Esta guía refleja la evolución del conocimiento dentro de la profe-
sión de dirección de proyectos; la guía también refleja las prácti-
cas comúnmente aceptadas para dirigir proyectos. PMBOK sirve
Jorge Valdés Garciatorres (PMP, ITIL, CC) Es socio Director de la firma global de consultoría y educación en procesos de negocio y dirección de proyectos
TenStep Latinoamerica. Participa como vicepresidente de Desarrollo Profesional en el PMI capitulo México en donde además es miembro del consejo editorial.
Es miembro del consejo editorial de SG y es miembro activo de Toastmasters International. jvaldex@tenstep.com.mx
46 MAY-JUL 2009
como un marco de referencia y establece un lenguaje común para
los practicantes de esta disciplina alrededor del mundo.
1. Redacción mejorada
En general, la 4ta. edición refleja un enfoque centrado en me-
jorar la consistencia y claridad de sus contenidos. Los equipos
que participaron en el proceso de actualización tomaron muy en
cuenta la eliminación de información redundante y agregaron al-
gunos párrafos explicativos para clarificar conceptos complejos.
Esto implicó una nueva redacción en todos los procesos, usando el
formato de verbo en infinitivo más sustantivo. El uso estándar de
verbos fue incorporado a todo el documento al describir conceptos
recurrentes para facilitar el entendimiento.
Las descripciones de los procesos, que por cierto se repiten en cuatro
lugares distintos, fueron re-escritos de manera más consistente a lo
largo del documento. Los sitios donde podemos encontrarlos son:
• Capítulo 3
• Al inicio de los capítulos de cada área de conocimiento
• En la primera oración de la descripción de procesos aplicables
• En el glosario.
2. Factores ambientales y activos de los procesos
de la organización
Se usó un enfoque estándar para discutir los factores ambientales
y los activos de los procesos de la organización; es decir, mientras
que en la versión 3 estos conceptos sólo se describían una sola
vez, en la versión 4 se listaron en las entradas y salidas de cada
proceso y se incluyeron descripciones específicas de cómo estos
conceptos deben ser entendidos en cada proceso en particular.
3. Estandarización del concepto Solicitud de
Cambios
Otra área en la que se incluyeron algunas clarificaciones fue todo lo
relativo a las solicitudes de cambio. En la 4ta. edición se incluye un
enfoque estándar para discutir los cambios solicitados, las acciones
preventivas, las acciones correctivas y la corrección de defectos. To-
dos estos conceptos se engloban ahora bajo el término: “solicitud de
www.sg.com.mx
cambios”. Esta revisión ayuda a racionalizar las entradas y salidas de
gran cantidad de procesos, mientras que a la vez provee visibilidad de
los distintos tipos de solicitud de cambios que pueden existir.
4. Procesos eliminados, nuevos y combinados
Procesos eliminados
En la 4ta. edición de La Guía PMBOK se borraron dos procesos:
Desarrollo de la Declaración Preliminar del Alcance y Planea-
ción del Alcance. En el primer caso, a decir del PMI, se tomó la
decisión de eliminarlo debido a que ésta es sólo una forma de
elaboración progresiva del acta de constitución del proyecto a
la declaración de alcance.
La Planeación del Alcance fue borrada debido a que la salida de
este proceso es el plan de administración del alcance, el cual
es parte del plan de administración del proyecto así que no era
necesario tener un proceso separado para tal efecto.
Procesos nuevos
A esta versión se incorporan 2 nuevos procesos: Identificar
Interesados y Recopilar Requisitos. Identificar Interesados se
mencionaba previamente en la declaración del alcance. Sin em-
bargo, debido a la importancia crítica que tiene esta actividad
para el éxito del proyecto, se agregó un proceso con múltiples
salidas. La incorporación del proceso Recopilar los Requisitos
representa una evolución en la profesión. Al igual que el caso
anterior, esto se mencionaba previamente en la declaración del
alcance, sin embargo, la disciplina ha evolucionado de tal ma-
nera que una gran cantidad de proyectos inician con un tipo de
recopilación de requisitos. Este proceso se añadió para recono-
cer esta situación.
Procesos Combinados
Planeación de Compras y Adquisiciones y Planeación de los Con-
tratos se combinaron en Planear las Compras. Solicitud de Res-
puestas de los Proveedores y Selección de Proveedores, fueron
combinados en un proceso que se denominó Planear las Compras.
5. Distinción entre plan para la dirección de proyectos
y documentos usados para dirigir el proyecto.
El plan para la dirección del proyecto y los documentos del pro-
yecto han sido diferenciados con mayor claridad. Esto se hizo
con el propósito de destacar los planes subsidiarios y las distin-
tas líneas base como los componentes principales de este plan;
mientras que los documentos del proyecto son usados para
ayudar al gerente de proyecto a dirigir el proyecto, por lo tanto
estos no son parte del plan.
Asimismo, se incluyó una distinción entre el acta del proyecto y la
declaración de alcance del proyecto. En la tercera edición existía un
nivel de redundancia con relación a los componentes de estos dos
elementos. La intención del PMI fue dejar establecido el hecho de
que existe una elaboración progresiva entre ambos elementos, a la
vez que se buscó establecer con claridad los elementos que se incor-
poran en cada documento para reducir la repetición.
www.sg.com.mx
6. Reemplazo de diagramas de flujo de procesos
por diagramas de flujo de datos
Los diagramas de flujo de procesos de cada capítulo fueron reempla-
zados con diagramas de flujo de datos que muestran de dónde viene
la información y hacia dónde va. Esto se hizo buscando mejorar el
entendimiento en cuanto a la fuente de la información y su destino
para cada proceso.
7. Complemento a la triple restricción
La triple restricción, que había venido sobreviviendo a las distintas
versiones y que era mencionada en la introducción de la tercera
edición, ha sido extendida para incluir otras restricciones poten-
ciales: calidad, recursos y riesgo. Sin embargo, dado que cada pro-
yecto es único, es probable que no todos los proyectos se vean
afectados por todas las restricciones potenciales.
8. Reconocimiento de la importancia de las
habilidades interpersonales del gerente de proyecto
Los gerentes de proyectos llevan a cabo el trabajo requerido a
través del equipo del proyecto y otros interesados. Los gerentes
de proyecto efectivos desarrollan un balance entre habilidades
técnicas, conceptuales e interpersonales que les ayudan a anali-
zar las situaciones y a interactuar de manera apropiada.
En la cuarta edición se agregó un nuevo anexo que describe las habili-
dades interpersonales más importantes para un gerente de proyecto:
• Liderazgo
• Integración de equipos
• Motivación
• Comunicación
• Influencia
• Toma de decisiones
• Conciencia cultural y política
• Negociación
Aunque no es una lista exhaustiva de las habilidades interperso-
nales que deben usar los gerentes de proyecto, este anexo busca
destacar las habilidades que, usadas apropiadamente, ayudan al
gerente de proyecto a obtener los resultados más favorables.
Conclusión
La Guía PMBOK es uno de los libros técnicos más vendidos
en el mundo. Supongo que tiene varios méritos para ello. La
actualización constante es uno, el otro es quizás que estas
actualizaciones provienen de personas como tú y como yo,
que han encontrado alguna forma de “más o menos hacer
bien algo” en un proyecto y quieren compartirlo.
El mérito del PMI es, además de la visión que ha tenido para
conjuntar estas prácticas, haber establecido los procesos
que permiten que el documento evolucione y refleje las cosas
que la comunidad de profesionales en esta disciplina, hemos
ido aprendiendo a base de muchas cicatrices de guerra.
MAY-JUL 2009 47
 // UML
Los requerimientos al estilo SysML
Estándar Mundial
Por Charlie Macías
Como ingenieros sabemos que cualquier
producto derivado del proceso de diseño en
ingeniería inicia de una declaración, por par-
te de un cliente, para resolver ya sea un pro-
blema o una necesidad. También sabemos
que existen varias formas de documentar los
requisitos que se tienen que satisfacer y/o
que limitan el número de soluciones posibles
para la problemática declarada, las cuales
van desde las maneras totalmente informa-
les y orientadas a la documentación hasta los
lenguajes y métodos formales que pueden
representar los requisitos de forma gráfica.
El diagrama de requerimientos definido en
SysML (Systems Modeling Language) tiene la
ventaja de haber sido creado ex profesamen-
te para documentar los requerimientos y sus
relaciones en un formato gráfico, sin estar
vinculado a una metodología en particular.
En este artículo veremos los principales ele-
mentos que conforman al diagrama de requi-
sitos definidos en la especificación de SysML e
ilustraremos la aplicación de los mismos usan-
do un ejemplo sencillo. Así mismo hablaremos
de las distintas representaciones alternativas
y aceptadas por la especificación.
El diagrama de requerimientos de
SysML: principales elementos
Requisito. Por supuesto el primer elemento
que describiremos es el requisito. Un re-
quisito está definido como un estereotipo
de una clase UML sujeta a una serie de res-
tricciones. Los requisitos estándar incluyen
propiedades para especificar un identifica-
dor único y la descripción textual del reque-
rimiento, sin embargo, el modelador puede
agregar propiedades para definir, por ejem-
plo, la prioridad del requerimiento.
Relación de contención. La relación de con-
tención vincula a un requerimiento complejo
Charlie Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación
práctica y consultoría en modelado de sistemas y negocios con UML, BPMN y SysML. Puedes contactarnos en info@milestone.com.mx www.milestone.com.mx
48 MAY-JUL 2009
con un conjunto de requerimientos conteni- ser asequible y atractivo para un mercado per-
dos más simples. Los requerimientos más teneciente a la clase media en México.
simples son el producto de la descomposición
del requerimiento complejo. Los requerimientos y la
relación de contención:
Dependencia derivada. Esta relación sirve Dividiendo para vencer
para relacionar a los requerimientos deriva- A continuación se presenta la descompo-
dos con los requerimientos originales. Los sición del requerimiento original en sus re-
requerimientos derivados, normalmente, son querimientos contenidos.
el resultado de aplicar un esfuerzo de análi-
sis sobre los requerimientos originales.
La declaración original del
problema: ¿así o más claro?
Lo primero que podemos observar es la repre-
sentación gráfica de los requerimientos. Estos
muestran los atributos estándar para el iden-
tificador único (id#) y para la descripción tex-
tual (txt). Por cuestiones de espacio se ha omi-
tido la descripción textual del requerimiento
original provisto por nuestro stakeholder. En
el diagrama también se puede observar el uso
de la relación de contención para relacionar el
requerimiento complejo S0.0 con sus requeri-
mientos contenidos S1.0, S2.0 y S3.0.
Los requisitos y la dependencia
derivada: soy, luego existo
El siguiente diagrama ejemplifica el uso de la
dependencia derivada. Supongamos que for-
mamos parte del equipo de diseño al que se le
ha encomendado la tarea de desarrollar un ca-
lentador de agua para uso residencial. Nuestro
proveedor de requerimientos nos ha indicado
que nuestro calentador debe ofrecer las pres-
taciones de un calentador a gas LP estándar,
para uso doméstico, que da servicio a una fa-
milia integrada por 5 personas, pero no debe
usar combustibles fósiles para calentar el agua
y debe minimizar al máximo las emisiones de
CO2 al medio ambiente. Así mismo, nos ha in-
dicado que se debe favorecer el uso de fuentes
de energía renovables y que el producto debe Diagrama1. Descomposición del requerimiento original
www.sg.com.mx
 hemos descrito y ejemplificado en este
artículo, SysML ofrece elementos adicio-
nales para expresar ideas tales como las
justificaciones de las deducciones (deri-
vaciones) o el conflicto potencial entre los
requerimientos, por mencionar algunos.
Así también soporta representaciones en
formato tabular de los requerimientos, te-
mas que abordaremos en el futuro.

Conclusión:
El diagrama de requerimientos
definido en SysML tiene la ventaja
de haber sido creado ex profesa-
mente para documentar los reque-
rimientos y sus relaciones en un
formato gráfico, sin estar vincu-
lado a una metodología en parti-
cular. Los requerimientos poseen
dos atributos estándar: el iden-
tificador único y la descripción
textual. La relación de contención
sirve para descomponer requeri-
mientos complejos.

La dependencia derivada se emplea

Diagrama 2. Requerimientos derivados
Tras una breve investigación descubriremos
que un calentador de gas LP estándar recibe
agua a una temperatura de 10°C y la entrega
a una temperatura que oscila entre los 50°C y
70°C. La dependencia derivada es la relación
que se puede observar entre los requisitos S1.1
(que surge al seguir descomponiendo el reque-
rimiento S1.0) y D1.1. Si bien el requerimiento
D1.1 no forma parte de los requerimientos origi-
nales, se puede derivar a partir de ellos.
Otros elementos para
especificar requerimientos:
Pero aún hay más
Además de los conceptos elementales que
para incorporar requerimientos que
se deducen a partir de los origina-
les. Si bien en el presente artículo
se ha empleado el diagrama de re-
querimientos de SysML para plas-
mar los requisitos de un producto
de ingeniería que cae en los domi-
nios de la ingeniería mecánica, su
uso puede aplicarse a los dominios
del desarrollo de productos de in-
geniería de software. Recordemos
que, finalmente, SysML está orien-
tado al dominio de la ingeniería de
sistemas en donde, normalmente,
los componentes que conforman
a sus productos derivados, son el
resultado del proceso de diseño de
múltiples ingenierías, entre ellas,
la ingeniería de software.

www.sg.com.mx MAY-JUL 2009 49

 // COLUMNA /*PROGRAMAR ES UN MODO DE VIDA*/
Evitando las Inyecciones de SQL
Asegurando la validación de tus entradas
Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del
Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo
de DGSCA-UNAM desde 1999.
E n la edición anterior de SG prometí que en esta columna trataría
temas relativos a la seguridad en cómputo y cómo escribir código
más confiable y más robusto.
Las vulnerabilidades más comunes son también las más fáciles de
explotar para un atacante (y utilizando algunas prácticas base, son
las más fáciles de evitar o corregir). Casi todas las vulnerabilidades
se originan por falta de validación (o exceso de confianza) en los
datos proporcionados por el usuario.
Prácticamente, la totalidad de los sistemas web que desarrollemos
procesarán datos provenientes de terceros: ya sea mostrando o gra-
bando lo expresado en formas HTML;determinando el flujo de nuestra
aplicación a través de rutas y parámetros ; «galletas» HTTP o incluso
-considerando la tendencia de migración hacia un esquema de «clo-
ud computing»- tomando resultados de procedimientos remotos en
sistemas no controlados por nosotros. A cada paso debemos emplear
datos en los que no confiamos. Esta puerta de entrada permite a un
atacante una amplia variedad de modalidades de intrusión. En gene-
ral, podemos hablar de ellas como inyección de código interpretado, y
en esta ocasión hablaremos específicamente de inyección de SQL.
En el desarrollo de sistemas debemos partir siempre del principio de
mínima confianza: No se debe confiar en ningún dato proveniente
de fuera de nuestro sistema, independientemente de quién sea el
usuario. Esto es especialmente importante cuando requerimos que
un elemento cruce entre las principales barreras de las diversas ca-
pas de nuestro sistema.
Tomemos como primer ejemplo al sistema de gestión de contenido
que usa SG. Si quisieran leer la edición anterior de esta columna, a la
que hice referencia hace algunas líneas, pueden encontrarla en:
http://www.sg.com.mx/content/view/825
Todos hemos analizado URLs, y resultará obvio que «825» corres-
ponda al ID de la nota en la base de datos, y que los componentes
«content» y «view» indican la operación que el sistema debe realizar
ante una solicitud. Ahora bien, ¿a qué me refiero con que cruzamos
las barreras entre las capas?
Enfoquémonos en el ID. Al analizar el URL, el ID es un pedazo de texto
(formalmente es una cadena que es recibida como parte del método
GET, uno de los métodos definidos para el protocolo HTTP). El servidor
web Apache que recibe mi solicitud interpreta este método GET y en-
50 MAY-JUL 2009
cuentra –utilizando mod_rewrite, indicado por el archivo htaccess– que
el contenido indicado por la ruta /content/view/* debe ser procesado
por el archivo index.php, que a su vez es manejado por el lenguaje
PHP. El archivo index.php corresponde en este caso al sistema Joomla,
que reconoce la ruta, convierte al ID en su representación numérica y
lo utiliza para pedir a la base de datos le entregue los datos relaciona-
dos con determinado artículo. Entonces, aquí podemos reconocer los
siguientes puntos principales de manipulación de la solicitud:
1. Apache recibe una solicitud HTTP, y la reescribe (via mod_rewrite),
indicando «content», «view» y «825» como parámetros a index.php.
2. PHP analiza, separa y estructura los parámetros recibidos para ser
utilizados por Joomla.
3. Joomla solicita el artículo 825 a la base de datos.
La variabilidad de los primeros pasos es en realidad menor, pero al
solicitar a la base de datos el artículo «825» (y este es el caso más sen-
cillo de todos) deben pasar muchas cosas. Primero que nada, «825»
es una cadena de caracteres. PHP es un lenguaje débilmente tipificado
(los números se convierten en cadenas y viceversa automáticamente
según sea requerido), pero una base de datos maneja tipos estricta-
mente. Como atacante, puedo buscar qué pasa si le pido al sistema
algo que no se espere, por ejemplo «825aaa». En este caso (¡felicida-
des!), el código PHP que invoca a la base de datos sí verifica que el tipo
de datos sea correcto: Hace una conversión a entero, y descarta lo que
sobra. Sin embargo (y no doy URLs por razones obvias), en muchas
ocasiones esto me llevaría a recibir un mensaje como el siguiente:
Warning: pg_execute() [ function.pg-execute]: Query failed: ERROR: invalid input syntax
for integer: “825aaa” in /home/(...)/index.php on line 192
Esto indicaría que uno de los parámetros fue pasado sin verificación de
PHP al motor de base de datos, y fue éste el que reconoció al error.
Ahora, esto no califica aún como inyección de SQL (dado que el mo-
tor de bases de datos supo reaccionar ante esta situación), pero es-
tamos prácticamente a las puertas. Podemos generalizar que cuan-
do un desarrollador no validó la entrada en un punto, habrá muchos
otros en que no lo haya hecho. Este error en particular nos indica que
el código contiene alguna construcción parecida a la siguiente:
SELECT * FROM articulo WHERE id = $id_art
La vulnerabilidad aquí consiste en que el programador no tomó en cuen-
ta que $id_art puede contener cualquier cosa enviada por el usuario.
¿Cómo puede un atacante aprovecharse de esto?
www.sg.com.mx
Presentaré a continuación algunos ejemplos,
evitando enfocarme a ningún lenguaje en es-
pecífico. Lo importante es cómo tratamos al
SQL generado. Para estos ejemplos, cambie-
mos un poco el caso de uso: En vez de ubicar
recursos, hablemos acerca de una de las ope-
raciones más comunes: La identificación de
un usuario vía login y contraseña. Suponga-
mos que el mismo sistema del código recién
mencionado utiliza la siguiente función para
validar a sus usuarios:
$data = $db->fetch(“SELECT id FROM usuarios
WHERE login = ‘$login’ AND passwd = ‘$passwd’”);
if ($data) { $uid = $data[0];
} else { print “<h1>Usuario inválido!</h1>”;
} consulta para cada uno de ellos) hará los
Aquí pueden apreciar la práctica muy cómo-
da y común de “interpolar” variables dentro
de una cadena. Muchos lenguajes permiten
construir cadenas donde se expande el con-
tenido de determinadas variables. En caso
de que su lenguaje favorito no maneje esta
característica, concatenar las sub-cadenas y
las variables nos lleva al mismo efecto.
Imaginemos ahora que el usuario ingresara el
login «fulano’;--». La clave de este ataque es
confundir a la base de datos para aceptar co-
mandos generados por el usuario. El ataque
completo se limita a cuatro caracteres: «‘;--».
Al cerrar la comilla e indicar (con el punto y
coma) que termina el comando, la base de
datos entiende que la solicitud se da por ter-
minada y lo que sigue es otro comando. La
sentencia quedaría de la siguiente forma:
SELECT id FROM usuarios WHERE login = ‘fulano’;--’
AND PASSWD = ‘’
Podríamos enviarle más de un comando conse-
cutivo que concluyera de forma coherente, pero
lo más sencillo es utilizar el doble guión indi-
cando que inicia un comentario. De este modo,
logramos vulnerar la seguridad del sistema, en-
trando como un usuario cuyo login conocemos,
aún desconociendo su contraseña.
Siguiendo con ejemplos similar y considerando
que típicamente el ID del administrador de un
sistema es el más bajo (ID=1), entonces imagi-
nemos el resultado de los siguientes nombres
de usuario falsos:
ninguno’ OR id = 1;--
‘; INSERT INTO usuarios (login, passwd) VALUES
(‘fulano’, ‘de tal’); --
‘; DROP TABLE usuarios; --
www.sg.com.mx
Podemos ver un ejemplo similar en la famo-
sa tira cómica de Bobby Tables (http://imgs.
xkcd.com/comics/exploits_of_a_mom.png).
¿Y qué podemos hacer? Protegerse de inyec-
ción de SQL es sencillo, pero hay que hacerlo
en prácticamente todas nuestras consultas,
y convertir nuestra manera natural de escri-
bir código en una segura.
La regla de oro es nunca cruzar fronteras in-
corporando datos no confiables, y esto no
sólo es muy sencillo sino que muchas veces
(específicamente cuando iteramos sobre un
conjunto de valores efectuando la misma
tiempos de respuesta de nuestro sistema
sensiblemente mejores. La respuesta es se-
parar la preparación de la ejecución de las
consultas. Al preparar una consulta, nuestro
motor de bases de datos la compila y prepara
las estructuras necesarias para recibir los pa-
rámetros a través de «placeholders», marca-
dores que serán substituídos por los valores
que indiquemos en una solicitud posterior.
Volvamos al ejemplo del login/contraseña:
$query = $db->prepare(‘SELECT id FROM usuarios
WHERE login = ? AND PASSWD = ?’);
$data = $query->execute($login, $passwd);
Los símbolos de interrogación son enviados
como literales a nuestra base de datos, que
sabe ya qué le pediremos y prepara los ín-
dices para respondernos. Podemos enviar
contenido arbitrario como login y password,
ya sin preocuparnos de si el motor lo inten-
tará interpretar.
Revisar todas las cadenas que enviamos a
nuestra base de datos puede parecer una ta-
rea tediosa, pero ante la facilidad de encon-
trar y explotar este tipo de vulnerabilidades,
bien vale la pena. En las referencias a conti-
nuación podrán leer mucho más acerca de la
anatomía de las inyecciones SQL, y diversas
maneras de explotarlas incluso cuando exis-
te cierto grado de validación.
» Por Gunnar Wolf
Referencias:
[en.wikipedia.org/wiki/SQL_injection]
[ ferruh.mavituna.com/sql-injection-
cheatsheet-oku/]
[msdn.microsoft.com/en-us/library/
ms161953.aspx]
[unixwiz.net/techtips/sql-injection.html]
MAY-JUL 2009 51
 // COLUMNA
El Modelo de Calidad Europeo TPI
Aplicación en México de TPI, un Modelo de Calidad Especializado en Prueba de Software
Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-
fundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en
Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado
frecuente en eventos relacionados con la prueba de software.
R ecientemente invitamos a México a Martin
Pol, reconocido gurú en Prueba de Software,
fundador de Poltec (empresa holandesa de
consultoría y certificación) y co-autor del mo-
delo europeo Test Process Improvement (TPI),
del cual plasmaremos aquí un breve análisis.
En la edición Agosto-Octubre 2008 rea-
lizábamos un comparativo general de
algunos modelos de calidad, entre los
cuales se encuentra TPI. Este Modelo de
Calidad Especializado en Pruebas (MCEP)
tiene una estructura matricial, tal como
lo mencionamos también en un número
previo de Software Guru, contemplando a
través de sus veinte áreas (ver Fig. 1), los
Figura 1. Categorías de madurez en TPI
52 MAY-JUL 2009
/*PRUEBA DE SOFTWARE*/
elementos clave a ser evaluados para me-
dir la madurez en el proceso de pruebas
de una organización.
Martin ofreció la conferencia magistral
“Global Trends in Software Testing”en Gua-
dalajara, Monterrey y el Distrito Federal.
En esta ponencia Martin comentó que pro-
bar un sistema de información no excluye al
resto de los elementos acompañantes del
software, como son el hardware, la docu-
mentación, los procedimientos, el material
para el entrenamiento y la implementación,
sino que éstos deberían ser probados tam-
bién como parte de un todo.
En otro de los comentarios destacados
de su charla, hizo referencia al hecho de
convertir la Prueba de Software en una
profesión dedicada, mas que seguirla
concibiendo como parte de una activi-
dad secundaria y “opcional”, que todos
y nadie realizan dentro de un proyecto de
desarrollo e implementación de sistemas
de información.
Basándose precisamente en tal primicia,
organizaciones en México han estado
analizando sistemáticamente la mejora
de sus procesos de prueba, buscando
entrenamiento para poner en producción
software con un mayor nivel de calidad.
Un ejemplo es la empresa Test Sourcing,
quien alcanzó el nivel 3 en TMM (Testing
Maturity Model) y el nivel “Eficiente” en TPI
en el assessment, cabe mencionar que la
evaluación estuvo a cargo de Martin Pol.
En la figura 2 se muestran los resultados ob-
tenidos marcados en rojo, esto nos permite
asomarnos a lo que en México se está logran-
do dentro del área de Prueba de Software.
Atendiendo los conceptos manejados en
TPI, podemos ver a éste como un mode-
lo especializado en prueba que distingue
ciertas áreas clave (veinte), evaluadas con
calificaciones desde la ‘A’ hasta la ‘D’ a lo
largo de distintos niveles (catorce: del 0 al
13); niveles que a su vez, si los compara-
mos contra otros modelos de calidad gené-
ricos como CMMI, podrían ser categoriza-
dos como: Controlado (del 1 al 5), Eficiente
(del 6 al 10) y Optimizado (del 11 al 13).
Para medir cada área clave, TPI contempla
una serie de check points sobre los elemen-
tos que deben ser cubiertos; de acuerdo a
www.sg.com.mx

Figura 2. Resultados en TPI de la empresa Test Sourcing
la cobertura de los mismos es la calificación
(A,B,C,D) obtenida. Por ejemplo: para el área
clave “Estimating and Planning”, se obten-
drá una calificación A si las estimaciones
se obtienen utilizando argumentos sólidos;
una calificación B si además de ello, las es-
timaciones se obtienen utilizando argumen-
tos estadísticos, modelos matemáticos, au-
tomatizados. Como puede verse en la Fig. 1,
B es la calificación máxima para dicha área
clave, la cual a su vez habrá de posicionar-
nos en el nivel 10 para dicha área.Como po-
demos observar, para cada área clave hay
una calificación máxima a obtener, la cual a
su vez podrá lograrse en interdependencia
con los niveles obtenidos en otras áreas. Se
Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado
también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad
Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.
www.sg.com.mx
recomienda obtener calificaciones tales que
nos permitan ubicarnos verticalmente en un
nivel similar en todas las áreas, en lugar de
enfocar todo el esfuerzo en intentar obtener
un nivel máximo en una sola de ellas.
Con respecto a los resultados de la Figura
2 obtenidos por la empresa mexicana Test
Sourcing, podemos observar que sus cali-
ficaciones caen dentro del niveles 8 al 10,
posicionándola detrás de organizaciones
cuyo ramo es de alto riesgo (donde si el
sistema falla, alguien muere: industria ae-
ronáutica, farmacéutica, etc.)
TPI es un modelo en el que, además de dejar
en claro el alcance de cada una de sus áreas
clave, se asocian check points a cada una de
dichas áreas, las interdependencias existen-
tes entre ellas son indispensables para alcan-
zar cada nivel, es importante tomar en cunta
las sugerencias de mejora para el logro de los
objetivos de dichos niveles.
Este modelo europeo ha comenzado a ser exi-
tosamente implementado en organizaciones
mexicanas, contribuyendo con ello a una ma-
yor competitividad de la industria mexicana del
software. La madurez del proceso de la organi-
zación que aplica las pruebas, es un factor im-
portante en la madurez del producto que sale
a un ambiente de producción y puede evitar
importantes pérdidas ocasionadas por la libe-
ración de software inmaduro.
Felicitación
Antes de despedirnos: en la edición anterior
decíamos que en marzo tendríamos como in-
vitado en e-Quallity a un experto internacional,
con quien ofreceríamos pláticas sobre temas
relacionados con los Modelos de Calidad Espe-
cializados en Prueba de Software en distintas
ciudades; nos referíamos a las pláticas de Mar-
tin Pol que ya mencionamos. Queremos enviar
un saludo a quienes con su entusiasta parti-
cipación demostraron su interés en el área de
Prueba de Software y felicitar a los ganadores
de los obsequios que se rifaron en cada ciudad
sede. ¡En horabuena!
¡Estén pendientes de nuestra próxima “Plá-
tica con Expertos”!
» Por Luis Vinicio León / Berenice Ruíz
MAY-JUL 2009 53
 // COLUMNA INVITADA
Programación Orientada a Negocios
El Paradigma de la Conciencia Financiera
Por Marco Dorantes
¿ Cuál es la última moda en tecnología?,
¿qué nuevo estilo dictan las corrientes co-
merciales de nuestra distinguida y glamo-
rosa tecnología de software?, ¿recuerdas el
revuelo que había por incorporar las ideas
de análisis y diseño estructurado?, ¿y más
tarde el apuro por presentar en términos de
or ientación a objetos todo lo que se mo-
viera en software? La lista de tendencias ha
incluido categorías tanto de diseño y arqui-
tectura como de procesos y productos.Lo in-
teresante es indagar, con una visión crítica,
los costos y beneficios de cada tendencia.
Un nuevo paradigma
¿Qué tal nos caería ahora una tendencia en la
categoría de las personas? Una que podría-
mos nombrar como: “Programación orienta-
da a finanzas” o “Programación orientada a
valor de negocio”. Una tendencia que derive
en un nuevo paradigma, en uno que res-
ponda a necesidades en nuestro contexto
actual. Después de todo, los paradigmas o
esquemas mentales que organizan nuestra
concepción del mundo, como los plantea
Thomas S. Kuhn , se forman precisamente
en respuesta al contexto.
Hoy en día, un programador de computado-
ras junto con cualquiera que decida aspec-
tos de diseño y arquitectura durante la crea-
ción de software —dentro de un contexto de
negocio— necesita contar con, al menos, el
entendimiento básico de los términos finan-
cieros relacionados con dichas decisiones.
Esta es mi tesis en este artículo.
La razón filosófica de fondo detrás de dicha
tesis es una de tipo ético, es decir, una que
Marco A. Dorantes es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos siste-
máticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software,
por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod
54 MAY-JUL 2009
involucra ejercer el sentido del deber con
base en un sistema de valores determinado
(por eso la tendencia propuesta cae en la
categoría de las personas). La razón prácti-
ca es que si el diseñador de software sólo
valora los aspectos técnicos y primorosos
de la tecnología, tendrá resultados signifi-
cativamente diferentes a si valora también
los aspectos financieros en sus decisiones
de diseño.
Para presentar evidencia de soporte para tal
razón, déjame comenzar poniendo un ejem-
plo simple: Un requerimiento de negocio en
un banco implica conectarse a una base de
datos para obtener información de la línea
de crédito de un cliente determinado. El di-
señador de software, —muy entusiasta de
la última moda tecnológica— determina:
“...lo que el banco necesita desarrollar es
un ‘framework’ de acceso para conectarse a
dicha base de datos pues éste le va a apor-
tar un sinfín de beneficios gracias a su gran
flexibilidad proyectada y poder de extensibi-
lidad que le permitirá acomodar una plétora
de requerimientos futuros fácilmente, sin
preocuparse más por volver a considerar di-
ferencia alguna con respecto al acceso a esa
base de datos en particular o a cualquier
otra, aun si fuera de otro proveedor. Por
tanto, no invertir en el desarrollo de esta in-
fraestructura aplicativa sería un grave error
por parte del banco, una falta de visión en la
evolución y la modernidad de la tecnología
de software...”
¿En realidad este banco necesitaría invertir
en el desarrollo de tal infraestructura apli-
cativa para acceso a datos?, ¿a eso se de-
dica?, ¿debería ser el foco de sus esfuerzos
desarrollar este tipo de piezas? ¿ese es su
negocio? ¿o tal vez debería mejor enfocarse
en desarrollar, de la mejor manera posible,
la lógica de soporte a su negocio?
Hay muchas piezas de software cuyo diseño
y desarrollo es algo muy interesante para un
programador, pues permiten experimentar
con técnicas y conceptos novedosos. El pro-
gramador puede realmente disfrutar pasar
una noche o un fin de semana programando
y avanzando en su oficio, pero cabe la pre-
gunta ¿es justificable hacer eso a cuenta del
negocio del cliente o empleador?
Valor de negocio
En el nuevo paradigma propuesto, la pre-
gunta básica que el diseñador de software
se debe hacer en cada decisión significativa
de diseño es: ¿cómo aporta esta decisión al
valor de negocio tanto en forma cualitativa
como cuantitativa?
Pero, ¿qué es el valor de negocio? Aquí
empezamos a notar uno de los rasgos que
hace diferente a este paradigma, pues si
bien en otros esquemas no se espera que
el diseñador de software tenga alguna no-
ción del significado del concepto de valor
de negocio, en este se asume que posee un
entendimiento básico de términos como:
valor presente neto de una inversión, tasa
interna de retorno, periodo de reembolso,
retorno o rentabilidad de inversión, punto
de equilibrio y otros indicadores clave de
un negocio o de una propuesta de valor
de negocio.
www.sg.com.mx

El valor de negocio es por lo que existen
las asociaciones, lucrativas o no. Está com-
puesto por los beneficios de acuerdo a la
misión establecida para la organización en
cuestión, ya sean ganancias económicas y
de otro tipo (servicios públicos, responsa-
bilidad ambiental, productividad, etcétera).
Cualquier cosa puede representar valor de
negocio, la clave es que esté debidamen-
te formulado como parte de un esquema
cuantitativo con el cual se proyecta la sos-
tenibilidad de dicho negocio.
En el ejemplo, si el banco aceptara la su-
puesta necesidad de desarrollar él mismo
sus propias piezas de infraestructura apli-
cativa para acceso a datos, tendría enton-
ces que (1) esperar a que tal cosa estuviera
lista para entonces empezar a contar los
supuestos beneficios, (2) asignar el tiempo
y esfuerzo de su gente para el desarrollo
correspondiente, tiempo y esfuerzo que no
estarán dedicados a atender el desarrollo
de piezas con una autentica prioridad de
negocio, (3) aumentar su nivel de inventario
con piezas que deben mantenerse correctas
durante todo el tiempo que duren hasta ser
retiradas, cada línea de código nueva en
la organización es una línea de código que
debe ser mantenida correcta con cargo a la
propia organización (está bien documenta-
do el efecto que tiene el nivel de inventario
sobre el valor de negocio), (4) correr el ries-
go de que todo ese tiempo y esfuerzo se de-
rroche si al paso del tiempo no se entregan
los beneficios esperados por causa de una
deficiente administración de la complejidad
en el desarrollo de ese tipo de componentes
de infraestructura aplicativa.
Un objetivo móvil
Lo único constante es el cambio. El valor
de negocio entregado a través de software
usualmente posee el peculiar rasgo de ser
susceptible de indefinición y ambigüedad.
www.sg.com.mx
“Un programador de computadoras junto con
cualquiera que decida aspectos de diseño y
arquitectura necesita el entendimiento
básico de los términos financieros relacionados
con sus decisiones”.
La razón es que el negocio puede tener una
idea de lo que quiere, pero existen un cierto
número de factores externos reales que no
le van a pedir permiso para cambiar, al con-
trario, el negocio tiene que adaptarse o mo-
rir. Por otro lado, hay factores internos; por
ejemplo, la sola presencia de una solución
tecnológica para un problema X, provoca
que se redefina dicho problema y sufra una
especie de mutación tal que ahora tenemos
un problema Y para el cual se requiere una
nueva solución. Es el modelo de co-evolu-
ción solución/problema planteado ya por
Frederick P. Brooks, Jr. (autor del clásico libro
The Mythical Man-Month: Essays on Soft-
ware Engineering) desde hace décadas.
El negocio necesita un proceso de desarrollo
de software que sea capaz de seguirle el rit-
mo, no al revés, el negocio ajustándose a los
dictados de un proceso rígido. Un proceso
de desarrollo adaptativo, que mantenga una
proporción razonable entre flexibilidad y dis-
ciplina y que principalmente esté enfocado
en atesorar los aprendizajes sobre la mar-
cha. Aprendizajes tanto del lado tecnológico
como del lado del negocio. Uno que desde
el inicio contemple que el negocio diga: “sí,
eso es lo que pedimos, pero ahora queremos
otra cosa y es esta...” y al mismo tiempo el
grupo de desarrollo domine las técnicas de
diseño para mantener una estructura limpia,
estable y flexible para el software, cuyo cos-
to de cambio no crezca exponencialmente.
Construyendo confianza
Un paradigma de programación orientada a va-
lor de negocio tiene también como premisa que
el proceso de desarrollo de software consiste
en un proceso de construcción de confianza, no
directamente en los individuos sino en que el
proyecto de desarrollo en su conjunto —la co-
laboración y conjunción de personal de negocio
y personal técnico— será capaz de entregar el
valor de negocio en los términos requeridos.
La capacidad de entrega de valor de nego-
cio implica tanto la capacidad del personal
de negocio para escoger prioridades, es-
pecificar funcionalidad, definir criterios de
aceptación, verificar funcionalidad, como la
capacidad del personal técnico para crear
el software que satisface lo prioritario a la
fecha, sin derrochar tiempo o dilatar la en-
trega por estar construyendo cosas que no
entregan valor de negocio hoy.
Una manera para construir dicha confian-
za en el proyecto es por medio de lograr
y mantener un ritmo periódico de entrega
de valor de negocio, el cual represente la
serie de pasos con los cuales se aborda
una aproximación sucesiva a lo que el ne-
gocio se va dando cuenta de lo que real-
mente quiere.
Conclusión:
Las conclusiones, junto con un planteamien-
to más extenso de esta idea de programación
orientada a valor de negocio, son desarrolla-
dos en el texto de un servidor: “Beneficios
sostenibles y desarrollo de software. ¿Cómo
obtener beneficios sostenibles por los ser-
vicios que incluyen desarrollo de software?
Parte I. El modelo adaptativo de desarrollo”,
el cual está publicado en forma electrónica
en la sección de artículos en línea del sitio
web de SG. Los invito a que lo revisen y me
hagan saber sus comentarios.
Referencias
[Kuhn, Thomas S. “La estructura
de la revoluciones científicas” ISBN
9681675991]
[Denne, Mark.; Cleland-Huang, Jane.
“Software by Numbers: Low-Risk, High-
Return Development” ISBN 0131407287]
[Poppendieck, Mary; Poppendieck, Tom.
“Implementing Lean Software Deve-
lopment: From Concept to Cash” ISBN
0321437381]
MAY-JUL 2009 55
 // COLUMNA /*tendencias en SOFTWARE*/
El Fin de la Plataforma Tecnológica
Rumbo a la masificación de aplicaciones
Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a
desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.
Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y
toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter
C on el título no me refiero a la desaparición del software, sino al
enfoque más allá de la infraestructura. Hoy se han acuñado nuevos
términos para nombrar polos de desarrollo de tecnología: Barcamp,
Twestival, Palermo Valley, Tequila Valley, Santiago Valley, Unacamp,
Super Happy Dev House… Todos ellos se refieren a un renovado espí-
ritu emprendedor, buscando adaptar ideologías culturales y sociales
en economías emergentes.
El futuro de la tecnología
La tecnología es una actividad humana que satisface las necesidades de
los usuarios. Las tareas para resolver estas necesidades pueden ser muy
simples o bastantes complejas. Los avances tecnológicos permiten satis-
facer necesidades de mayor nivel en la Pirámide de Maslow. Esto crea una
espiral; al avanzar la tecnología, nuevos escenarios de necesidades sur-
gen para ser satisfechos. El ciclo terminará con la personalización masiva
de soluciones para el consumidor. Es imposible hacer esto sin la “nube”.La
creación de una nueva dimensión de técnica requiere involucramiento de
consumidores para la confección de diversas especificaciones, para cu-
brir eficientemente sus necesidades. Es indispensable un nuevo ecosiste-
ma interactivo, donde el producto-servicio sea mejorado. La masificación
significa que las empresas proveedoras no solo desarrollarán soluciones
individuales como anteriormente lo hacían. El número de combinaciones
que las aplicaciones ofrecerán difícilmente será predecible.
Cambio de mentalidad en la audiencia con rela-
ción al uso de tecnología
En los últimos treinta años hemos cambiado la forma de ver los datos
y la información, ahora es usada como commodity. La tecnología está
entrelazada en las actividades de la vida diaria. La transformación que
estamos viviendo cruza las barreras socio-psicológicas y socio-cultu-
rales. Es interesante mencionar que quienes experimentan el cambio,
desean mucho más de él. La PC permitió experiencias “personales”
de cómputo. Hemos evolucionamos a servicios ligeros en dispositivos
sencillos. Saltamos del P2P (peer to peer) al F2F (friend to friend). Es-
tos productos y servicios presentan algunos factores en común:
• Crecimiento en la adquisición de PCs y dispositivos portátiles.
• Crecimiento en la industria de desarrollo de software.
• Aumento en la confianza al acceso de aplicaciones vía Web.
• Mayor nivel de confiabilidad tecnológica.
• Altas inversiones en el área de infraestructura básica.
El panorama empresarial cambió completamente con la tecnología, des-
de su estructura hasta el control de “indicadores de un negocio sano”.
Incluyendo modelos basados en publicidad muy dirigida, pago mediante
suscripciones y la venta de bienes digitales.
56 MAY-JUL 2009
El cambio de ingeniería se está dando, con frecuencia es necesario obser-
var la evolución del “cómputo en la nube”, Geo-hosting, administración
de múltiples versiones, automatización total, etc. El cambio cultural es el
más importante y el que menos se ha entendido. Esto incluye:
• Operaciones ya no es solo una parte del equipo, ahora se transforma en
una nueva área de ingeniería.
•El modelo mental de compensación debe pasar del “lanzamiento” al
“mantener en operación”
• La disponibilidad del sitio es siempre la mayor prioridad del equipo
• En un servicio mundial, no existen “horas no pico”
• El desarrollo del servicio nunca terminará.
•La selección de servicios a ofrecer en la nube es distinta al modelo tra-
dicional, tiene que ver con cuales servicios son más fáciles de consumir a
corto plazo
La sociedad de la información
En abril del 2008 hice algunas observaciones en mi blog sobre “Innova-
ción social” (sn.im/enfbh ). Hoy se han materializado estos pronósti-
cos en ciudades de América Latina; En Venezuela, el proyecto UnaCamp
(www.unasurs.com) se enfoca en 3 partes fundamentales:
1.Tecnología: Nuevas capacidades para aplicaciones web en estadios
tempranos, tecnologías de código abierto, protocolos sociales, etc.
2. Soluciones locales para mejorar la calidad de vida: educación, sa-
lud, seguridad,etc.
3. Integración latinoamericana: ¿Cómo nosotros, los ciudadanos, po-
demos unir América Latina?
Estas iniciativas están apoyadas por herramientas como Twitter, que jue-
gan un papel protagónico en crear un “web de tiempo real” dando mayor
dinamismo a los denominados “grupos de usuarios”.
Conclusión:
El discurso tecnológico ha cambiado en la última década, no
solo después de la re calibración económica o de los temas de
ahorro de energía. Hay que entender el mundo actual y apostar a
ser líderes de “la siguiente generación” de soluciones. La inercia
“pesa”: El Web 2.0 ya tiene 5 años y continua siendo objetivo de
muchos grupos emergentes. Usemos la tecnología para coordi-
narnos mejor y alinear el impacto total hacia América Latina.
» Por Luis Daniel Soto
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009 57
 // fundamentos
Personal Software Process (PSP)
Reducción de defectos y estimaciones más exactas
Por Consuelo Jiménez
PSP representa una metodología o un marco de trabajo desarrollado
en 1993 por Watts S. Humphrey. Lo importante al construir software
es tener un proceso disciplinado para llevar a cabo el desarrollo e
implementar mejoras para lograr resultados de calidad. Enfocada
principalmente en el rol del programador, ayuda a que este ponga
atención en aspectos de planeación, diseño, estándares y revisiones
al detalle de lo que va realizando, registrando todo aquello en for-
mas o plantillas que han sido diseñadas por Humphrey.
La metodología maneja un conjunto de scripts que especifican los
requerimientos de entrada, el proceso que debe de seguirse y los
resultados esperados, todo esto enfocado a cada fase de la metodo-
logía (ver figura 1).
Figura 1. Flujo de Procesos PSP
Esta metodología esta apoyada por una herramienta computacional de-
sarrollada por el Instituto de Carnegie Mellon, que genera una serie de
registros con información valiosa para llevar a cabo la siguiente planea-
ción y para actualizar el plan al terminar cada programa de software.
Cuando se termina el curso de PSP y se empieza a realizar su primer
proyecto siguiendo la nueva metodología, uno mismo se da cuenta
del tiempo que a veces invierte incorrectamente cuando quiere diri-
girse directamente a codificar el programa, en lugar de haber realiza-
do un análisis y un diseño general de la solución. Al ir avanzando en
el desarrollo de los diferentes proyectos uno se acostumbra a definir
cuántas líneas de código se programan, esto basado en un diseño
conceptual y en aquel código que uno ha desarrollado, cuántas lí-
Ing. Ma. del Consuelo Jiménez Fernández, profesor asociado de la Universidad de Monterrey en el Departamento de Ciencias Computacionales desde hace 22
años, certificada en PSP developer y PSP Instructor por el SEI of Carnegie Mellon University, con maestria en informática administrativa, especialista en desarrollo
de software educativo, calidad de software y metodologías de desarrollo de software.
58 MAY-JUL 2009
neas pueden servir como base, que tanto código podemos reutilizar
e incluso cuantas líneas modificarás o borrarás del código base que
se usará. Lo importante es que toda esta información se registra y
uno puede planear con más exactitud tamaños y tiempo relaciona-
dos al desarrollo de su programa.
Cuando codificamos directamente utilizando un IDE (Medio ambien-
te de desarrollo integrado) estamos de una u otra forma tratando de
quitar errores de sintaxis a través de la compilación, sin considerar
que la mayor cantidad de errores serán por lógica y que muchas de
las veces estamos depurándolos hasta la fase de prueba, cuando es-
tos errores deberían de ser descubiertos si revisáramos a conscien-
cia el diseño realizado. Lo que realmente se espera es que el tiempo
en hacer las pruebas sea solo el tiempo que le tome en capturar los
datos para cada caso de prueba y que los resultados esperados sean
realmente igual a los resultados obtenidos. Quizás en muy pocas
ocasiones esto no suceda.
La revisión incorporada en la metodología implica la realización de
un documento completo del diseño definiendo la parte operacional,
lógica, de estados y funcional; asimismo será importante checar el
cumplimiento de estándares tanto en el diseño como en la construc-
ción y revisar este código generado no usando el compilador, sino de
forma manual para encontrar la mayor cantidad de errores antes de
la primera compilación, siendo los errores de lógica verificados con
tablas de rastreo o tablas de ejecución, entre otras.
Tu productividad mejorará, los defectos antes cometidos serán mi-
nimizados o eliminados esto debido a su registro constante, tus
estimaciones serán más certeras pudiendo cumplir con las fechas
prometidas al líder de proyecto.
No está por demás mencionar que es importante que quien esté de-
sarrollando y vaya a aplicar la metodología debe dominar el lengua-
je de programación. Creo que esta es un área de oportunidad para
aquellos que enseñamos a programar pues el inculcar desde los
primeros semestres aspectos valiosos de esta metodología es fun-
damental para que al llegar al final de una carrera se evite programar
con vicios o errores graves.
Referencias:
[Humphrey, Watts. “PSP,A Self Improvement Process For Software
Engineers”]
[sei.cmu.edu/certification/psp.html]
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009
 // TECNOLOGÍA /*INFRAESTRUCTURA*/
Grid Computing
La unión hace la fuerza
Por Beatríz Ríos y Luis Joyanes
Mientras que la programación paralela se basa en el concepto de “di-
vide y vencerás”, la tecnología grid computing (cómputo en malla)
trata de integrar ésta filosofía bajo la estrategia de “la unión hace
la fuerza”. De esta forma, se busca aprovechar recursos de cómputo
geográficamente distribuidos en un gran número de computadoras
en el mundo para conformar grandes “ordenadores virtuales” capa-
ces de procesar cantidades de información inimaginable en una sola
computadora, o incluso en un solo centro de datos.
Antecedentes
Los primeros conceptos de grid computing se exploraron en 1995 con
el experimento “I-WAY2”, en el que se usaron redes de alta velocidad
para conectar 17 sitios en Norteamérica y habilitar una infraestructu-
ra para soporte de los laboratorios virtuales.
Por otro lado, Seti@Home es uno de los proyectos más conocidos en
los que se aplica este concepto. Éste cuenta con miles de ordenado-
res repartidos en todo el mundo que ceden tiempo de sus procesa-
dores, ciclos de proceso desocupados, para analizar señales buscan-
do patrones inteligentes extraterrestres.
Características
Un sistema de grid computing se refiere a aquel que:
1. Coordina recursos distribuidos que no están sujetos a un control
centralizado.
2. Usa protocolos e interfaces estándar.
3. Proporciona calidad de servicio no trivial.
Grid y P2P
La unión de ordenadores que comparten ciclos de procesamiento no usa-
dos, cada vez aparece más claramente como una futura aplicación de In-
ternet. Los conceptos de grid y peer to peer se basan en la idea básica de
compartir recursos, sin embargo existen algunas diferencias. La principal
diferencia es que P2P es un esquema descentralizado donde todos los
nodos son cumplen el mismo rol, mientras que grid nace de una estructu-
ra de nodos más controlada y jerarquizada en centros científicos.
BeatrÍz Ríos Velázquez Catedrática del Instituto Tecnológico de San Luis Potosí, México. Maestra en Ciencias de la computación, Diplomada de Estudios Avanza-
dos en Informática por la Universidad Pontifica de Salamanca en Madrid. Ha trabajado en la Banca, en el sector de telecomunicaciones, en el desarrollo de sistemas
para la empresa y en la docencia. Actualmente se encuentra realizando investigación para el desarrollo de su tesis doctoral en Tecnologías de la Información, Web
2.0, redes sociales, usabilidad y empresas 2.0.
60 MAY-JUL 2009
Funcionamiento
El funcionamiento de un grid requiere de un middleware que asegure
la comunicación transparente entre diferentes ordenadores reparti-
dos en distintos lugares geográficos.
El segundo elemento es un motor de búsqueda que no sólo en-
contrará los datos que el usuario necesite, sino también las herra-
mientas para analizarlos y la potencia de cálculo necesaria para
realizar las operaciones.
Por último, las tareas de procesamiento son distribuidos entre los
nodos donde hay capacidad disponible, regresando los resultados
integrados al usuario.
Beneficios
Como se podrán imaginar, algunos beneficios de este esquema son:
• Alquiler de recursos
• Amortización de recursos propios
• Gran potencia de cálculo a precio bajo sin adquirir equipamiento
• Mayor colaboración y compartir recursos entre varios centros
• Creación de organizaciones virtuales
• Negocios basados en proveer recursos
Las organizaciones virtuales habilitadas por grids
Foster, Kesselman y Tuecke, precursores del cómputo en grid, plan-
tean la existencia de organizaciones virtuales (OV) como puntos de
partida de este enfoque. Una organización virtual es un conjunto de
individuos, instituciones o empresas, definida por reglas que contro-
lan el modo en que comparten sus recursos.
Algunos ejemplos de organizaciones virtuales son:
• Los proveedores de servicios de aplicaciones o almacenamiento.
• Equipos de trabajo empresarial realizando análisis y planeación
estratégica.
• Miembros de una planta de energía evaluando trabajo de campo.
• Universidades involucradas en un proyecto de investigación conjunto.
www.sg.com.mx
 “Foster, Kesselman y Tuecke, precursores de
la computación “Grid”, plantean la
existencia de organizaciones virtuales (OV)
como puntos de partida de este enfoque”.

Usos de la tecnología Grid

• En Gobiernos y Organizaciones Internacionales: En respuesta
ante desastres como: inundaciones, incendios, terrorismo, en plani-
ficación urbana, modelos económicos, etc.
• En el mundo de la Medicina: La unión de recursos tales como ba-
ses de datos administrativas, archivos de historias clínicas e imáge-
nes médicas de instrumentos especializados abre la puerta a una
gran variedad de nuevos procedimientos de diagnóstico mejorados
gracias a la ayuda de computadoras, en base a un análisis rápido
de imágenes médicas complejas y la comparación automática con
archivos distribuidos para encontrar casos similares.
• En la Educación: Las bibliotecas electrónicas y los centros de e-
educación se beneficiarán de las herramientas basadas en “Grid”
para el acceso a datos dispersos y la creación de aulas virtuales con
estudiantes, recursos y profesores distribuidos.
• Empresas y Grandes Corporaciones: Las grandes empresas tienen
delegaciones, datos, personal y recursos distribuidos por todo el
mundo. Un enfoque basado en grid permitirá la creación de medios
para realizar aplicaciones a gran escala tales como el diseño asis-
tido por computadora utilizando simultáneamente recursos situa-
dos en muchos lugares. Otra consecuencia de la tecnología grid es
la creación de organizaciones virtuales: individuos, instituciones y
organizaciones que comparten un objetivo común y que para lograr
alcanzarlo, eligen compartir sus recursos, lo que se traduce en un
acceso directo a ordenadores, programas, ficheros, datos, sensores
y redes.
Conclusiones
La virtualización es una respuesta a la problemática de la
optimización de las infraestructuras. En concreto, la virtua-
lización de las aplicaciones permite convertir software en
servicios, que se ejecutan sin instalación en los equipos
clientes o en el servidor, en un contexto aislado y con un
mínimo impacto en las infraestructuras existentes. La tec-
nología de virtualización de varios proveedores permite
minimizar los costos de compatibilidad de programas, mi-
graciones a nuevos entornos, distribución de aplicaciones
al equipo cliente hasta la terminación del ciclo de vida del
software . El resultado es una infraestructura más optimiza-
da, ciclos reducidos de puesta en marcha de aplicaciones y
por lo tanto, menores costos de gestión en la infraestructu-
ra. El cómputo en malla requiere de nuevos modelos de pro-
gramación ya que introduce grandes retos: heterogeneidad
y rendimiento que no se encuentran en computadoras en
paralelas, pero el problema básico de programación es el
mismo. Se pueden usar técnicas clásicas de programación
de abstracción, encapsulamiento por objetos, así como
otros modelos que puedan surgir. Al final de este camino,
los servicios informáticos serán entendidos con la misma
filosofía que los servicios de gas, de electricidad o de agua.
Estas tecnologías nos convertirán en meros consumidores
que no tienen por qué conocer el origen, distribución, loca-
lización y mantenimiento de los mismos.
Referencias
[Eiguren, I. “Los pioneros del Grid” .(2008) ]
[Fernandez, S. “El Grid al servicio de la e-ciencia”.CESGA 2007.]
[Fox, G.; Thomas, M.“Grid Computing Environments “, Community
Grids Lab, Indiana: Indiana University, Austin: TACC, University of
Texas, Feb 2003.]
[Joyanes, Luis. “CIENCIA 2.0: Hacia la Ciencia Web con la Web 2.0
y Web Semántica (nuevo paradigma en la I+D+i)” en Semana de la
Ciencia de Castilla y León. Salamanca: Universidad Pontificia de Sa-
lamanca: 13 de noviembre, 2008. ]
[astic.es]
[setiathome.ssl.berkeley.edu/]
[super.unam.mx/]

Luis Joyanes Aguilar Dr. Ingeniería Informática, Dr. Sociología, Lic. Ciencias físicas, Lic. Enseñanza superior militar y Dr. Honoris y causa por la Universidad
Antenor Orrego de Trujillo (Perú). Catedrático, Ex-Decano de la facultad de Informática y Director del departamento de posgrado de la Universidad Pontificia de
Salamanca en Madrid. Profesor del posgrado de sociología en Guatemala, Universidad de Oviedo, Complutense y Politécnica, en España. Ha publicado más de
40 libros y 80 artículos sobre tecnologías de la Información, metodologías y diversos lenguajes de programación.

www.sg.com.mx MAY-JUL 2009 61

 // tecnología /*gadgets*/

Esta sección es presentada por Geek

www.geek.com.mx

Alienware
M17
Las portátiles de Alienware siempre se han caracterizado no sólo por
sus vistosos diseños, sino también por su poder. La M17 es el nuevo
modelo y la primera en incorporar la tarjeta ATI CrossFireX y el procesa-
dor Quad-Core Intel móvil. La llaman “la solución que la industria nece-
sita”, debido a su agresivo desempeño. Una de sus ventajas es que no
sólo va dirigida a entusiastas videojugadores, sino también a aquellos
amantes de las laptops con diseños innovadores, un tanto toscos.
La M17 cuenta con Procesador Intel Core 2 Extreme QX9300, el pri-
mer Quad-Core móvil, que ofrece desempeño y eficiencia con capaci-
dades multitarea con una velocidad de más del 50% que las genera-
ciones anteriores de procesadores; y de ahí saltamos al GPU armado
con una ATI Mobility Radeon HD3870 para video HD, DirectX 10.1
para juegos de nueva generación que corren a más de 80% que las
soluciones tradicionales de GPUs. Memoria de 4GB de DDR3. Disco
duro de 500GB ligado a una configuración RAID 0 para almacena-
miento masivo de 1TB; que equivale más o menos a 160 juegos, 250
películas o alrededor de 250 mil canciones, ufff. No podemos pasar
por alto su pantalla de 17 pulgadas de “alta definición extrema” con
resolución de 1920 X 1200 que exalta la reproducción de discos Blu-
ray y videos HD. En cuestión de seguridad su panel de control te da
acceso a programas exclusivos como AlienFusion para administrar
el sistema, AlienSense un software de reconocimiento facial y Alien-
Touch; no hay manera de que algún intruso se meta con ella.
Amazon
Kindle DX
Después del lanzamiento
de Kindle de 6.5” el año
pasado, ahora Amazon de-
cidió crecerlo tanto en ta-
maño como en capacidad y
características.
El Kindle DX ofrece una pantalla en escala de 16 grises
de 9.7 pulgadas. Cuenta con soporte para archivos PDF
utilizando Adobe Reader Mobile, de tal manera que pue-
des enviar por correo o vía USB hacia tu Kindle cualquier
tipo de documento en PDF y lo podrás leer, no importa si
tiene gráficos, tablas, notas, etcétera.
La pantalla utiliza tinta real y no requiere luz, evitando así
el malestar en los ojos después de estar mucho tiempo
expuesto, como pasa con otros dispositivos; también po-
see capacidad rotatoria, por tanto te permite leer en hori-
zontal o vertical, sólo es cuestión de moverlo y la pantalla
se ajustará de inmediato (sí como un iPhone). Su memo-
ria de 3.3GB permite almacenar más de 3 mil 500 libros
que se pueden descargar desde Amazon sin necesidad
de buscar hot spots ni utilizar una computadora. Hoy en
día existen alrededor de 275 mil libros disponibles para
descarga en Kindle que incluyen 107 de los 112 New York
Times Best Sellers disponibles hasta el momento.

Firebox
R2-D2 Projection Alarm Clock
Si para estas fechas, después de las crisis y las contingencias sanitarias no hay poder humano que te obligue o te
haga levantarte de la cama. Incluso luego de haber intentado con la alarma de tu celular, la del despertador que te
regaló tu mamá y una llamada de despertador... podrías intentar algo nuevo, más divertido, como por ejemplo el
R2-D2. Como uno de los personajes favoritos de Star Wars y uno de los mejores androides de la galaxia, esta versión
licenciada de 16 centímetros de altura, proyecta la hora sobre la pared o techo, en caso de que te de pereza mover
la cabeza, sus patas se ajustan para que la proyección quede exactamente en el punto que deseas, pero eso no
esto, en caso de que tu habitación se de esas que se iluminan con el primer rayo del sol, nuestro querido R2 lleva
consigo un display LCD para no fallarte nunca. Quizá una de sus mejores características es que emite una alarma de
60 segundos seguidos con sus tradicionales sonidos y chirridos para que lo que escuches sea como música para tus
oídos. (Cuidado fanáticos de Star Wars). Utiliza dos baterías AAA y una de botón G13. Cuenta con un panel de control
desde el cual se selecciona el modo de despliegue de la hora, fecha o segundos; puede ser de 12 o 24 horas.

62 MAY-JUL 2009 www.sg.com.mx

 INDEX

DIRECTORIO Anunciante Página Sitio

Alpha Consultoría 39 www.alpha-consultoria.com

Ciudades Digitales 59 www.ciudades.gob.mx
e-Quallity 51 www.e-quallity.net
gelattina 43 www.gelattina.com
IDC 63 www.idclatin.com/mexico
Itera 19 www.iteraprocess.com
JPE Consultores 45 www.jpeconsultores.com
Matersys 2F,1 www.matersys.com.mx
Milestone Consulting 4F www.milestone.com.mx
NYCE 3F www.nyce.org.mx
Praxis 9 www.praxis.com.mx
SG 09 Conferencia y Expo 11 www.sg.com.mx/sg09
SG Campus 57 www.sgcampus.com.mx

TENEMOS UN ESPACIO
RESERVADO PARA TI
Si deseas anunciarte contáctanos
en el (55) 5239 5502 o en
publicidad@sg.com.mx

www.sg.com.mx MAY-JUL 2009 63

 // CARRERA
Reputación Digital
Cuidado con lo que subes a la Web
Por Fernando García
Hoy día, cuando necesitas buscar información, referencias o
simplemente localizar personas lo primero que haces es tratar
de encontrar esa información en algún “Buscador” de internet
como Live o cualquier otro de los existentes. Esto ya es una prác-
tica normal, es muy común que la gente busque información de
la pareja sentimental por este medio y es también común que
los interesados en tus servicios profesionales lo hagan.
Actualmente es casi imposible no dejar huella en internet, por su-
puesto algunos dejan más huellas que otros. Desde el momento
en que te registras para obtener un correo electrónico gratuito o
para los más entendidos, crear algún blog, microblog, perfil en
alguna red social, etc. Con esto ya estas dejando algo de tu infor-
mación en internet, lo cual puede ser un arma de doble filo desde
el punto de vista profesional, una vez indexado por el buscador tu
información ya quedo almacenada para la posteridad.
Cuántos de ustedes se han buscado y lo primero que ven es una
foto que algún amigo o que ustedes mismos subieron donde
apareces en estado inconveniente, comentarios que escribie-
ron en algún blog que pudieran ser mal interpretados o fuera de
contexto. Esto podría ser usado en tu contra.
Hay ejemplos muy claros donde personas han perdido su em-
pleo debido a comentarios que hicieron en sus blogs sobre su
trabajo, su jefe o su empresa.
Con esto no intento decir que está mal subir fotos o expresarte
libremente. Mi propuesta va más allá. Consiste en dejar “Huella
Digital” de forma inteligente y que aporte valor a tu reputación
profesional o como lo llamo yo “Reputación Digital”. La pregun-
ta obligada es: ¿Cómo dejar esa huella?
Afortunadamente hay numerosas formas de hacerlo, varias técni-
cas y muchos mecanismos que se pueden acoplar perfectamente
a todos los estilos y preferencias para implementar una estrategia
de este tipo, es por eso que en lugar de darles “un paso a paso”
mejor les planteo las inquietudes a resolver y ustedes podrán ele-
gir libremente la metodología que mejor les parezca.
Fernando García Loera actualmente trabaja en Microsoft como MVP Lead para Latinoamérica, es experto en tecnología, Social Media y Web 2.0. Ha impar-
tido varias conferencias en México y el extranjero, juez en varios concursos de desarrollo, y prolífico blogger. Puedes seguirlo en blogs.msdn.com/mvplead,
www.ferglo.com y @ferglo
64 MAY-JUL 2009
/*REPUTACION DIGITAL*/
· ¿Qué quiero que las personas digan de mi?
· ¿Cómo quiero ser visto profesionalmente?
· ¿Qué tipo de información quiero que encuentren sobre mi?
· ¿Cómo quiero que encuentren mi información?
Una vez contestadas estas preguntas el siguiente
paso es determinar tu “Estrategia”
· ¿Cuál es mi estatus hoy día en mi reputación?
· ¿Donde quiero llegar?
· ¿Qué herramientas y/o medios existen acordes a mis necesida-
des y preferencias?
· ¿En qué tiempo quiero lograr mis objetivos? (corto, mediano o
largo plazo)
· ¿Qué tipo de entrenamiento, capacitación, mejora profesional
y/o de conocimientos necesito?
· ¿Cómo puedo medir mi éxito o fracaso? (Métricas, herramien-
tas, etc…)
· ¿Mi modelo escala en caso de ser necesario?
· ¿Quién o quienes ya lo están haciendo y cómo lo hacen?
En mi experiencia he visto que siguiendo estas
reglas los resultados pueden ser exponenciales
· Ser reconocido como experto.
· Ser un líder de opinión.
· Registrar todas las actividades.
· Concentrar toda la evidencia en un solo lugar.
· Incrementar tu network.
Estos cinco puntos no son la panacea, claro está, pero es un
excelente inicio, está claro que hay dos cosas que resultan fun-
damentales “Ser constante” y sobre todo “Disfrutar al hacerlo”
sin estas dos variables nada de lo anterior será posible.
Cada uno de los puntos anteriores por si solos requieren un tra-
to a mayor profundidad y para cada uno hay técnicas, métodos,
herramientas y prácticas que ayudan a conseguirlos. En colabo-
raciones posteriores los trataré por separado.
www.sg.com.mx
www.sg.com.mx MAY-JUL 2009 57
No. 24 www.softwareguru.com.mx SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA Mayo-Julio 2009