SG24

Software Guru CONOCIMIENTO EN PRÁCTICA

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

May

o-Ju

lio 2

00

9

No.24 • Mayo-Julio 2009 • www.sg.com.mx

[ Tutorial ] AzureNoticias • Industria • Fundamentos • Carrera • Infraestructura • Gadgets

No.

24

• Auditoría de procesos

• Arquitectura de software

• Requerimientos con SysML

México, $65.00

[ ENTREVISTA ]

Jorge ZavalaInnovación y desarrollo de negocios globales

Desarrollo para smartphones

[ REPORTAJE ]Software enNuevo León

http://www.matersys.com

MAY-JUL 2009 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialAlejandro Escamilla

Arte y DiseñoDafne 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.

ColaboradoresBenjamí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 WebNathanael Gutiérrez

[email protected]

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

directorio

Editorial

// CONTENIDO

02

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.

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

MAY-JUL 2009www.sg.com.mx

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Programar es un Modo 50de Vida por Gunnar Wolf

Prueba de Software 52por Luis Vinicio León

Columna Invitada 54por Marco Dorantes

Tendencias en Software 56por Luis Daniel Soto

20

Productos

Lo QUE VIENE 12RubyMine, CloudBurst, Dryad y Moblin

HERRaMIENTaS 14Web testing con Visual Studio

TUToRIaL 16Aplicaciones en la Nube con Azure

Prácticas

CaSo DE ESTUDIo 34SG GuíaCompartimos algunas prácticas aplicadas durante el desarrollo de este proyecto.

MEJoRa DE PRoCESoS 36MoProSoft y la auditoría de ProcesosGuía para la realización de una auditoría.

aSEGURaMIENTo DE CaLIDaD 38Medición y análisisRecomendaciones para obtener buenas métricas.

aRQUITECTURa 40El Valor de los Ciclos Guiados por la arquitectura del SoftwareAlejandro Bianchi comparte los beneficios de un ciclo de vida centrado en la arquitectura de software.

PRoGRaMaCIÓN 44Programación DeclarativaUn vistazo a sus características y ventajas.

PM CoRNER 46Revisión de la 4ta edición de la Guía PMBoKPresentamos los principales cambios que sufrió la guía PMBOK en esta nueva versión.

UML 48Los requerimientos al estilo SysMLAprenderemos los principales elementos parahacer diagramas al estilo de SYSML.

EN PORTADA 22

Desarrollo de aplicacionespara smartphones

contenido may - jul 2009

03

En Cada Número

NoTICIaS y EVENToS 04

INDUSTRIa 06

FUNDaMENToS 58

EntrevistaJorge ZavalaInnovación y desarrollo de negocios globales

INFRaESTRUCTURa 60

GaDGETS 62

CaRRERa 64

22


// NOTICIAS

04

IBM Industry Forum 2009Con 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éxicoFIRSTCon 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


// EVENTOS

05

Global Trends in Software TestingEl 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.

20 y 21 de mayo 20095a. Conferencia Anual de TI Service ManagementPink ElephantHotel Maria Isabel Sheraton, Ciudad de MéxicoInfo: www.pinkelephant.comContacto: [email protected]

10 a 12 de junio 2009XVIII Reunión Nacional de Directores de Escuelas y Facultades de Informática y ComputaciónANIEITepic, NayaritInfo: www.aniei.org.mx

14 al 16 de junio 2009GITMA - ITESM Congreso Mundial de TITecnológico de Monterrey, Campus Santa Fe.Info: www.gitma-la.orgContacto: [email protected]

22 y 23 de junio 20095a. Cumbre de Gobierno y TecnologíaIDC MéxicoHacienda de los Morales, Ciudad de MéxicoInfo: www.idclatin.com/eventsContacto: [email protected]

14 y 15 de Julio 2009X Encuentro Iberoamericano de Ciudades DigitalesGobierno del Estado de VeracruzWorld Trade Center, Veracruz.Info: www.ciudades.gob.mx

15 y 16 de julio 2009Agile Project Management: Innovation in ActionCutter ConsortiumHotel Marriott, Ciudad de MéxicoInfo: www.cutter.com.mxContacto: [email protected]

Eventos de software libreEl 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.

MAY-JUL 2009 www.sg.com.mx1606

// 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 comenzarLa 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.

CSOFTMTYEl 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 mercado2. Desarrollo de profesionales de software3. Desarrollo de empresas y empresarios4. Desarrollo de infraestructura5. Sustentabilidad y alto valor agregado6. 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.

Desarrollo de Capital HumanoEn 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 TIEl 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


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 universidadesPor 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 mercadoEl 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-

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ónDentro 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.

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

Más información en: [www.csoftmty.org] [www.ti.org.mx] [www.piit.com.mx]

1707

MIT Cluster en el PIIT


Picando piedra: Primera ParteRecoRdando a las peRsonas que apoRtaRon su gRanito de aRena paRa elevaR la calidad del softwaRe mexicano

/*TEJIENDO NUESTRA RED*/// COLUMNA

Escribir 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-

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.

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.


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

09

• 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

http://www.praxis.com.mx


/*MEJORA CONTINUA*/// COLUMNA

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

La Cultura de Calidadtomemos 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.

La 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-

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-

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

http://www.sg.com.mx/sg09


IBM WebSphere CloudBurst ApplianceHabilitació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.

Dryad y DryadLINQProcesamiento 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/dryadresearch.microsoft.com/en-us/projects/dryadlinq

MoblinLinux 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

12

/* LO QUE VIENE*/// PRODUCTOS

RubyMinePor 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


http://www.sg.com.mx/guia


Web Testing Utilizando Visual Studio Team Edition for Software Testers cReando web tests de maneRa Rápida, sencilla y eficientePor Benjamín Ruvalcaba

/*HERRAMIENTAS*/// PRODUCTOS

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

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.

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.

Captura1. Creación de nuevo proyecto

Captura 2. Despliegue de la prueba y el árbol

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.


Captura 3. Prueba con validaciones

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.

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

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.

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.

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.

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

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.


Aplicaciones en la Nube con AzurecompRendiendo como funciona este nuevo esquemaPor Miguel Angel Morán y Misael Monterroca

/*TUTORIAL*/// PRODUCTOS

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

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.

• 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)

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.

Figura 1. Conceptos que retoma el cómputo en la nube.


Figura 2. El stack de tecnologías que ofrece Azure

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.

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

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 AzureWindows 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 -> Project3. En Project Types seleccionar “Cloud Service” y en los templates seleccionar “Web Cloud Service”.


/*TUTORIAL*/// PRODUCTOS

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.

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)

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>

6. Abrimos el code-behind y en el evento Page_Load agregaremos un mensaje a nuestro Label:

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

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.

Figura 2. Arbol de elementos del proyecto.

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

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

11. El portal de Azure posteriormente solicitará un nombre único para la aplicación (único a nivel mundial).

Figura 4. Publicando la aplicación en Azure.


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.

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]

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.

Figura 5. Escogiendo el ambiente correspondiente.

http://www.iteraprocess.com


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


¿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

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.


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.


Un vistazo al pasado y presente del smartphonepor 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.

En 1983 Casio lanzó el PF-3000, que fue el pri-mer “diario digital”. Esta era una calculadora digital que incluía capacidades para agenda telefónica, calendario y memo (notas).

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.

Referencias:www.wikipedia.comwww.palmsource.comwww.byte.com


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.

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.

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


Un modelo con alto potencial en aplicaciones móvilespor 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

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óvilHoy 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


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 resolverHay 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

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 empezarAú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.

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.


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.

Tecnologías para RIAs móvilesExiste 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 LiteFlash 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/5jypycKuneri Lite www.kunerilite.netBlocket PC Open Source: opensource.blocketpc.comSWX Format swxformat.org

Una interesante oferta para desarrollo móvilpor Edgar Parada


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.

Proyectos complementarios a Flash LiteEn 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ónEn 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 ConclusionesDespué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.

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


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

Objective-CObjective 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.

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

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

Cocoa Touch

Media

Core Services

Core OS

¿Por dónde empezar?Por Juan José Karam


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.

MediaSi tienes en mente un video juego o una apli-cación con contenidos, ésta es la capa que

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 TouchEs 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:


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

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

XcodeAmigable 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

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

InstrumentsPartiendo 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 FinalesIdentifica 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.


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 diferenciarsePuedo 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-

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óvilesEl 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.

Carlos Silva es Gerente de Alianzas de Research In Motion, fabricante de los dispositivos BlackBerry. Puede ser contactado en [email protected] y vía su blog personal www.csilva.net. Las opiniones expresada son suyas y no necesariamente reflejan las de RIM.

Tomando ventaja de la transformación del mercadopor Carlos Silva


/*CASO DE ESTUDIO*/// PRÁCTICAS

Diseño de la Interfaz de SG GuíaDetrá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ónNotamos 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 eficiente1. Brief CreativoEste 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.

2. Arquitectura de informaciónDurante 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áficoLas 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.


4. MaquetaciónUna 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 ContenidoLa 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 & TestingLa 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.

ConclusiónLa 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.

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

La prueba de la cajuelaDurante 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.


/*MEJORA DE PROCESOS*/// PRÁCTICAS

MoProSoft y la Auditoría a Procesos de Softwareel sistema maDam asociaDo a moProsoftPor Yolanda Fernández, Leticia Arévalo, Jesús Soria

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

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 da por concluida la auditoría con acciones de recomendación y seguimiento. Ver Figura 1.

La auditoría a la calidad de procesos de softwareSi los procesos de interés son los de la ge-neración y mantenimiento de software, la auditoría de calidad se orienta a verificar si la organización cumple con los linea-mientos establecidos en un modelo de ca-lidad de software específico.

Una auditoría es similar a una evaluación, aunque con algunas diferencias. En una evaluación el objetivo primordial es de-terminar un nivel de madurez especificado en el modelo de software que se establece

La metodología para auditorías de MoProSoftMoProSoft define documentos que des-criben lo que se debe auditar para cada uno de los procesos en las tres catego-rías: Alta Dirección, Gerencia y Opera-ción. En cada documento aparece la serie ordenada de acciones y procedimientos para revisar y calificar actividades en cada etapa del proceso. La estructura de los documentos puede adaptarse a los li-neamientos de implantación del modelo en una organización en particular. En la Tabla 1 se resumen los nombres y conte-nidos de los documentos para cada fase de la auditoría.

de acuerdo a cómo se han implantado los procesos. Una consecuencia de la evalua-ción es sugerir mejoras que permitan al-canzar el siguiente nivel de madurez. Hay una retroalimentación explícita de resulta-dos en este sentido.

Por otro lado, la auditoría es una revisión detallada de cómo se están realizando las cosas y si están cumpliéndose o no los re-quisitos prescritos en una norma o mode-lo, apelando a observaciones directas de agentes externos. El dictamen puede ser de cumplimiento de lo establecido en la norma o de efectividad en el alcance de metas de calidad determinadas.

Figura 1. Fases de Auditoría (adaptada de Arter, 1994)


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

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

Tabla 1. Documentos y su contenido por fases de la auditoría

* Opcional, en su caso.

FASE NOMBRE DOCUMENTO CONTENIDO

Propósito de auditoría

Alcance de auditoría

Plan de auditoría

Programa de auditoría

Métodos de

recolección de datos

Informe de Auditoría

Resumen General de

Auditoría

Cierre de Auditoría

Plan de Acciones

Correctivas*

Preparación

Ejecución

Informe

Cierre

Qué se persigue y qué debe calificarse para el

proceso.

Identificar la profundidad de la revisión

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-

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.

Calendarización detallada de actividades

Cuestionarios

Plantillas de entrevistas

Especificación de la revisión documental

Definición de encuestas

Técnicas de muestreo

Matriz de doble entrada Requisitos/Evidencias

Narrativa detallada de hallazgos y ubicación

del hallazgo (en qué parte del proceso)

Buenas prácticas*

Narrativa resumida de hallazgos y logros

significativos y métodos utilizados.

Dictamen formal de la auditoría.

Como anexos: Plan de Auditoría, Listas de

Verificación llenas, Informe de Auditoría y

Plan de Acciones Correctivas*

Informe de situaciones relevantes*

El Sistema MADAMPara 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]

ConclusiónLa metodología resulta de la aplicación de los principios de auditoría a la norma MoProSoft. Se siguen las fases prevale-cientes en las auditorías para revisar los procesos consideran-do el nivel 1 de capacidades: Proceso Realizado de MoProSoft. Se proponen documentos de apoyo al auditor que identifican los aspectos relevantes, como el propósito de la auditoría, su alcance, los puntos auditables y el informe de cierre. Se men-cionó el sistema asociado MADAM que maneja documentos adaptables para auditar a una organización.

Figura 2. Carátula Documento Cierre de Auditoría.


/*ASEGURAMIENTO DE CALIDAD*/// PRÁCTICAS

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

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.

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.


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.

“No hay mejor punto de comparación que nuestro propio antes, ahora y después”.

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” ]

Figura 1. Gráfica de seguimiento a defectos

http://www.alpha-consultoria.com


/*ARQUITECTURA DE SOFTWARE*/// PRÁCTICAS

El Valor de los Ciclos Guiados por la Arquitectura del SoftwarePonienDo el enfoQue en los objetivos De negocios y los atributos De caliDaD Del ProDuctoPor 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.

Una definición de arquitectura de softwareLa 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


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 arquitecturaSi 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:

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

41

“La arquitectura de un producto complejo de software es uno de los artefactos más

importantes del ciclo de desarrollo”.

Figura 1. Modelo de ciclo de vida guiado por arquitecturas


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:

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.

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]

42

/*ARQUITECTURA DE SOFTWARE*/// PRÁCTICAS

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.

Tabla 1. Métodos, roles involucrados y etapa del ciclo de vida


http://www.gelattina.com


/*PROGRAMACIÓN*/// PRÁCTICAS

Programación Declarativa conociénDola y entenDienDo su aPlicación realPor 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 declarativaCuando 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

“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 ejemploVeamos 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.

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.


Lenguajes declarativosExisten 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.

“... indicar qué es lo que se debe hacer en lugar de cómo hacerlo nos protege de cambios en el

contexto tecnológico”.

ConclusiónAhora, 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.

http://www.jpeconsultores.com


// PM CORNER

Revisión de la 4ta edición de la Guía PMBOKcambios 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 PMILos 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 PMBOKLa 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

como un marco de referencia y establece un lenguaje común para los practicantes de esta disciplina alrededor del mundo.

1. Redacción mejoradaEn 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ónSe 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 CambiosOtra á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

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


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 combinadosProcesos eliminadosEn 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 nuevosA 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 CombinadosPlaneació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.

6. Reemplazo de diagramas de flujo de procesos por diagramas de flujo de datosLos 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ónLa 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 proyectoLos 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ónLa 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.


lOs RequeRiMientOs al estilO sysMlestánDar munDial

Por Charlie Macías

// UML

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

con un conjunto de requerimientos conteni-dos más simples. Los requerimientos más simples son el producto de la descomposición del requerimiento complejo.

Dependencia derivada. Esta relación sirve para relacionar a los requerimientos deriva-dos con los requerimientos originales. Los requerimientos derivados, normalmente, son 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 existoEl 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

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 [email protected] www.milestone.com.mx

ser asequible y atractivo para un mercado per-teneciente a la clase media en México.

Los requerimientos y la relación de contención: Dividiendo para vencerA continuación se presenta la descompo-sición del requerimiento original en sus re-querimientos contenidos.

Diagrama1. Descomposición del requerimiento original


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ásAdemás de los conceptos elementales que

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

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.

http://www.sg.com.mx


/*PROGRAMAR ES UN MODO DE VIDA*/// COLUMNA

En 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-

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?

Evitando las Inyecciones de SQLaseguranDo 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.

50


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>”;}

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; --

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 consulta para cada uno de ellos) hará los 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]

http://www.e-quallity.net


Figura 1. Categorías de madurez en TPI

Recientemente 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

// COLUMNA /*PRUEBA DE SOFTWARE*/

El Modelo de Calidad Europeo TPIaPlicació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.

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


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ónAntes 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

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.

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

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


¿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

// COLUMNA INVITADA

Programación Orientada a Negociosel ParaDigma De la conciencia financiera

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.

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

Por Marco Dorantes


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.

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]

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.

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.

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.

“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”.


/*TENDENCIAS EN SOFTWARE*/// COLUMNA

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. [email protected] luisdans.com\Twitter

Con 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íaLa 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íaEn 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.

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ónEn 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”.

» Por Luis Daniel Soto

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.


http://www.sgcampus.com.mx


Personal Software Process (PSP)reDucción De Defectos y estimaciones más exactasPor Consuelo Jiménez

// fUNDAMENTOS

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.

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

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

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]

Figura 1. Flujo de Procesos PSP


http://www.ciudades.gob.mx


// TECNOLOGÍA /*INFRAESTRUCTURA*/

Grid Computingla unión hace la fuerzaPor 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.

AntecedentesLos 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ísticasUn 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 P2PLa 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.

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

BeneficiosComo 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 gridsFoster, 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.

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.


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.

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.

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/]

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

“Foster, Kesselman y Tuecke, precursores de la computación “Grid”, plantean la

existencia de organizaciones virtuales (OV) como puntos de partida de este enfoque”.


/*GADGETS*/// TECNOLOGÍA

Amazon

Kindle DXDespué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.

Alienware

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

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.

Esta sección es presentada por Geek

www.geek.com.mx


INDEX

Anunciante Página Sitio

Alpha Consultoría 39 www.alpha-consultoria.comCiudades Digitales 59 www.ciudades.gob.mxe-Quallity 51 www.e-quallity.netgelattina 43 www.gelattina.comIDC 63 www.idclatin.com/mexico Itera 19 www.iteraprocess.comJPE Consultores 45 www.jpeconsultores.comMatersys 2F,1 www.matersys.com.mxMilestone Consulting 4F www.milestone.com.mxNYCE 3F www.nyce.org.mxPraxis 9 www.praxis.com.mxSG 09 Conferencia y Expo 11 www.sg.com.mx/sg09SG Campus 57 www.sgcampus.com.mx

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

DIRECTORIO

http://www.idclatin.com/mexico

http://www.alpha-consultoria.com

http://www.ciudades.gob.mx

http://www.e-quallity.ne

http://www.gelattina.com

http://www.idclatin.com/mexico

http://www.iteraprocess.com

http://www.jpconsultores.com

http://www.matersys.com.mx

http://www.milestone.com.mx

http://www.nyce.org.mx

http://www.praxis.com.mx

http://www.sg.com.mx/sg09

http://www.sgcampus.com.mx


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.

· ¿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.

64

// CARRERA /*REPUTACION DIGITAL*/

Reputación DigitalcuiDaDo con lo Que subes a la webPor Fernando García

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


http://www.nyce.org.mx

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

May

o-Ju

lio 2

00

9N

o. 2

4

http://www.milestone.com.mx

SG24

Documents

Transcript of SG24