SG24 (Mayo-Julio 2009)

• Auditoría de procesos • Arquitectura de software • Requerimientos con SysML

Software Guru CONOCIMIENTO EN PRÁCTICA No.24 • Mayo-Julio 2009 • www.sg.com.mx

[ REPORTAJE ]

Software en Nuevo León

[ ENTREVISTA ]

Jorge Zavala Innovación y desarrollo de negocios globales

México, $65.00

Desarrollo para smartphones Noticias • Industria • Fundamentos • Carrera • Infraestructura • Gadgets

[ Tutorial ]

Azure

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Alejandro Escamilla

Editorial

Arte y Diseño Dafne Ortega, Oscar Samano Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Francisco Camargo, Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo - ITESM; Emilio Osorio - Sistemas Humanos; Luis Vinicio León - e-Quallity.

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 airosos. Los lenguajes de programación han madurado, el mercado está en el momento 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 interesante con Jorge Zavala, quien actualmente dirige la oficina de TechBA en Silicon Valley.

Jorge nos proporciona una interesante visión de cómo convertir las ideas en grandes empresas, y nos comparte su perspectiva sobre la vida en Silicon Valley.

En esta edición incluimos un reportaje especial 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 coincidencia 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 estrenando 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 colaboraren y evalúen las herramientas, servicios, capacitación y aplicaciones contenidos en SG Guía.

» Equipo Editorial

02

MAY-JUL 2009

Colaboradores Benjamín Ruvalcaba, Miguel Angel Morán, Misael Monterroca, Germán Dominguez, Héctor Obregón, Edgar Parada, José Karam, Carlos Silva, Romeo Márquez, Gunnar Wolf Yolanda Fernández, Leticia Arevalo, Jesús Soria, Edith Martínez Alejandro Bianchi, Gastón Milano, Charlie Macías, Marco Dorantes, Consuelo Jiménez, Beatríz Ríos, Luis Joyanes, Susana Tamayo, Fernando García.

Ventas Claudia Perea Marketing y RP Paulina Olivares Circulación y Administración Edgar Dorantes Desarrollo Web Nathanael Gutiérrez Contacto info@sg.com.mx +52 55 5239 5502 SG Software Guru es una publicación trimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Queda prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en mayo de 2009 en Roma Color, S.A. de C.V. Distribuido por Sepomex.

www.sg.com.mx

contenido may - jul 2009

22

EN PORTADA

22

Desarrollo de aplicaciones para smartphones

Productos Lo QUE VIENE 12 RubyMine, CloudBurst, Dryad y Moblin Herramientas Web testing con Visual Studio

14

TUTORIAL 16 Aplicaciones en la Nube con Azure

Prácticas CASO DE ESTUDIO SG Guía

Columnas Tejiendo Nuestra Red por Hanna Oktaba

08

Prueba de Software por Luis Vinicio León

52

Mejora Continua por Luis Cuellar

10

Columna Invitada por Marco Dorantes

54

Programar es un Modo de Vida por Gunnar Wolf

50

Tendencias en Software por Luis Daniel Soto

56

Compartimos algunas prácticas aplicadas durante el desarrollo de este proyecto.

MEJORA DE PROCESOS 36 MoProSoft y la Auditoría de Procesos Guía para la realización de una auditoría.

ASEGURAMIENTO DE CALIDAD Medición y Análisis

38

Recomendaciones para obtener buenas métricas.

ARQUITECTURA El Valor de los Ciclos Guiados por la Arquitectura del Software

En Cada Número Noticias y Eventos

04

INFRAESTRUCTURA

60

INDUSTRIA

06

GADGETS

62

FUNDAMENTOS

58

CARRERA

64

40

Alejandro Bianchi comparte los beneficios de un ciclo de vida centrado en la arquitectura de software.

PROGRAMACIÓN Programación Declarativa

44

Un vistazo a sus características y ventajas.

PM CORNER Revisión de la 4ta edición de la Guía PMBOK

20

34

46

Entrevista

Presentamos los principales cambios que sufrió la guía PMBOK en esta nueva versión.

Innovación y desarrollo de negocios globales

UML 48 Los requerimientos al estilo SysML

Jorge Zavala

Aprenderemos los principales elementos para hacer diagramas al estilo de SYSML.

www.sg.com.mx

MAY-JUL 2009

03

// NOTICIAS

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

La estructura de la agenda fue muy buena y brindó contenido para todo tipo de intereses, ya que el primer día consistió en conferencias magistrales con enfoque de negocio, mientras que el segundo día fue dominado por sesiones simultáneas orientadas 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 éxito el evento Tendencias 2009, evento que Select ha organizado de forma consecutiva desde hace 16 años. El evento estuvo enfocado 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 colaboran tanto en organizaciones públicas y privadas, así como representantes de la industria de TIC, todos ellos interesados en identificar las estrategias para competir y aprovechar la tecnología.

MéxicoFIRST Con la meta de incrementar la cantidad de personas certificadas en nuestro país, la iniciativa de CANIETI “MéxicoFIRST” presentó en conjunto con la empresa Sun Microsystems, el proyecto enfocado 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 obtener hasta un 80% de descuento.

Mayor información en www.certificatemexico.com

04

MAY-JUL 2009

www.sg.com.mx

// EVENTOs

20 y 21 de mayo 2009

5a. Conferencia Anual de TI Service Management

Pink Elephant Hotel Maria Isabel Sheraton, Ciudad de México Info: www.pinkelephant.com Contacto: info.mx@pinkelephant.com

10 a 12 de junio 2009

XVIII Reunión Nacional de Directores de Escuelas y Facultades de Informática y Computación ANIEI Tepic, Nayarit Info: www.aniei.org.mx

14 al 16 de junio 2009

GITMA - ITESM Congreso Mundial de TI Tecnológico de Monterrey, Campus Santa Fe. Info: www.gitma-la.org Contacto: gustavo.pares@itesm.mx

22 y 23 de junio 2009

5a. Cumbre de Gobierno y Tecnología IDC México Hacienda de los Morales, Ciudad de México Info: www.idclatin.com/events Contacto: idc@simrel.com.mx

14 y 15 de Julio 2009

X Encuentro Iberoamericano de Ciudades Digitales Gobierno del Estado de Veracruz World Trade Center, Veracruz.

Info: www.ciudades.gob.mx

15 y 16 de julio 2009

Agile Project Management: Innovation in Action Cutter Consortium Hotel Marriott, Ciudad de México Info: www.cutter.com.mx Contacto: agalindo@cutter.com.mx

Global Trends in Software Testing

Eventos de software libre

El pasado mes de marzo la empresa e-Quallity invitó a México al reconocido gurú del testing Martin Pol, fundador de Poltec (empresa holandesa de consultoría y certificación) y coautor 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, enfocando su plática en la importancia que tiene el uso de las pruebas de software para incrementar las capacidades de evitar los riesgos empresariales.

El mes de abril fue bastante agitado para los entusiastas del software libre, ya que en menos de dos semanas se realizaron cuatro eventos importantes.

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

www.sg.com.mx

Empezamos con el 4to Congreso de Software Libre organizado 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 Fernando 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 Latinoamericano de Software Libre (FLISOL) 2009, el cual conjuntó sedes en más de 200 ciudades en 18 países.

MAY-JUL 2009

05

// INDUSTRIA

Software en Nuevo León Nuevo León es un estado de gran importancia en términos de la industria 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 grandes empresas de la India como Infosys, Sasken y Wipro han establecido centros de operación en esta entidad.

Algunos números para comenzar La industria de software en Nuevo León está compuesta por más de 300 empresas que emplean más de 7 mil personas y generan ingresos 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 certificaciones de calidad después del Distrito Federal.

CSOFTMTY El Consejo de Software de Nuevo León (CSOFTMTY) es el organismo que coordina lo que se denomina la triple hélice: academia, empresas y gobierno. Esta asociación civil es la responsable de desarrollar y asegurar el cumplimiento de las estrategias para el fortalecimiento de la industria de software en esta región.

Para ello, CSOFTMTY se enfoca en siete líneas de acción: 1. Desarrollo de mercado 2. Desarrollo de profesionales de software 3. Desarrollo de empresas y empresarios 4. Desarrollo de infraestructura 5. Sustentabilidad y alto valor agregado 6. Accesibilidad a programas y fondos económicos Existen 22 miembros de los cuales 12 son empresas, 3 organismos empresariales (AETI, CANIETI y ORIGO), 5 universidades (ITESM, TEC Milenio, UANL, UDEM y UR), un representante del Gobierno de Nuevo León y uno del Instituto de Innovación y Transferencia de Tecnología (I2T2).

Una característica fundamental de CSOFTMTY es que no es un organismo gubernamental, sino que es un organismo independiente que vincula a la triple hélice: Empresas, Academia y Gobierno para lograr un propósito común.

06 16

MAY-JUL 2009

Desarrollo de Capital Humano En términos de capital humano, Nuevo León enfrenta una problemá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 establecido 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 preponderante 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 requeridas por los mercados internacionales.

Es por esto que esta es la línea estratégica de mayor prioridad dentro del plan de trabajo de CSOFTMTY; dentro de la cual hay dos iniciativas concretas en las que se está trabajando: • Una campaña de promoción entre los jóvenes para que estudien carreras relacionadas con las TIC’s • La creación del Instituto de Desarrollo de Talento de TI, único en su tipo en México

Instituto de Desarrollo de Talento de TI El Instituto de Desarrollo de Talento de TI (IDETI) tiene como finalidad 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 profesionistas 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, Universidad Autónoma de Nuevo León y Universidad de Monterrey.

Los programas de estudio de este Instituto se refieren específicamente a la certificación en: • Conceptos de hardware y software de sistemas • Fundamentos de programación • Bases de datos • Metodologías de desarrollo de software • Análisis de algoritmos • Conceptos de desarrollo orientado a objetos • Diseño de interfaces • Tecnologías Web • Conceptos Cliente – Servidor www.sg.com.mx

Solo para TI “Solo para TI” es una campaña para fomentar que los jóvenes próximos a entrar a la universidad elijan estudiar carreras relacionadas a las tecnologías de información. Asimismo, se ha iniciado una estrategia pre-universitaria en la que a través de centros de computación aplicada y la capacitación de maestros de escuelas públicas de primaria y secundaria se fomente el conocimiento y gusto por las tecnologías de información y comunicaciones.

Vinculación con universidades Por su parte, las empresas y universidades también llevan a cabo actividades de vinculación que resulten en disponibilidad de más capital humano y con mayor especialización y experiencia: • Las universidades ofrecen espacio de ubicación a nuevas empresas 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 absorció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 conocimientos 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 universidades 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.

midor de los productos y servicios de las empresas locales. Se promueve 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 proveedores locales en la ley de adquisiciones.

Innovación Dentro del Consejo, entró en operación un nuevo comité de innovación en el cual se busca desarrollar la alta especialización del sector basado 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 diferentes definiciones del concepto. De igual manera, se buscará desarrollar innovación en los productos y servicios para obtener márgenes más grandes en la industria.

Infraestructura En Nuevo León existe el Parque de Investigación e Innovación Tecnoló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, biotecnología y nanotecnología.

Dentro del PITT esta por inaugurarse el Monterrey IT Cluster, un conjunto 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.

Desarrollo de mercado El mercado local de software y servicios TI en Nuevo León se encuentra 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 destacar 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 consuwww.sg.com.mx

MIT Cluster en el PIIT

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

17 07

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Picando piedra: Primera Parte Recordando a las personas que aportaron su granito de arena para elevar la calidad del software mexicano La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

E

scribir la columna número 25 para Software Gurú me puso nostálgica. A lo largo de casi veintiséis años de trabajo en México he conocido mucha gente, que desde sus espacios, han impulsado la adopción de buenas prácticas en la industria de software. Para hacer un pequeño reconocimiento de su labor, decidí hacer un recuento de sus aportaciones para que las nuevas 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 impartirla. 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 Simula 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 Soluciones Avanzadas, una revista semejante a lo que hoy es SG. Esta revista fue un excelente medio de transferencia de conocimiento 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ándares de procesos y muchos temas más. Desgraciadamente la revista dejo de existir en 1999.

• 1992, su servidora empezó a dar las primeras conferencias sobre ¿Por qué está de moda OO? en los foros de Instituto Mexicano 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 participar 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 Administración del proyecto SPICE. La herramienta de Evaluación de Procesos de Software desarrollada por certum fue denomina-

08

MAY-JUL 2009

da Official SPICE Assessment Instrument. Según mi conocimiento fue el primer directivo de la industria y tal vez último hasta la fecha, quien se involucró personalmente en desarrollar un está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 habí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. Entre 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 Laboratorio 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, SWCMM, PSP, TSP). En los últimos años estos cursos fueron enriquecidos con la participación de las instructoras: Ana Briseño (consultora independiente), Cecilia Pérez (IBM de México) y Elsa Ramírez (Praxis). Hasta la fecha Lupita y yo hemos dirigido 48 tesis de maestría relacionadas con diversos temas de calidad en procesos de software. www.sg.com.mx

• 1999, Gloria Quintanilla, Francisco López Lira, Lupita Ibargüengoitia y su servidora fundan la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS). A mitad de 1999 el Círculo de Calidad de Software, tuvo tantos adeptos que se decidió formalizar su existencia 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 Alquicira, 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, organizamos cinco seminarios de calidad de software con invitados extranjeros y nacionales. Armamos el primer Diplomado de Calidad de Software que entre 2002 y 2006 fue ofrecido en el Distrito Federal y en el interior del país. También, editamos cuadernos de calidad

www.sg.com.mx

de software basados en las tesis de maestría. En los últimos años de la actividad de la AMCIS se crearon sus capítulos en Jalisco (Luis Vinicio León), Nuevo León (Héctor González), Veracruz (Agustín Lagunes) 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 solamente en mis recuerdos personales usando mi memoria de viejita. Invito a todos mis colegas y a los lectores de SG para que complementen la información y que corrijan los datos erróneos.

» Por Hanna Oktaba

MAY-JUL 2009

09

// COLUMNA

/*MEJORA CONTINUA*/

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

L

a semana pasada terminé un libro llamado The Culture Code (El Código de la Cultura). El libro está enfocado principalmente en el área de mercadeo y desarrollo de nuevos productos. Expone el hecho de que para hacer 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 definen a los automóviles actuales. Pero, si preguntamos más a nivel subconsciente a través de dinámicas de roles, manejo de recuerdos y demás, las respuestas son totalmente diferentes. Un ejemplo de dinámica sería el adentrarse a preguntar tus primeros recuerdos de un automóvil y las emociones que estos recuerdos te traen, al hacer esto se descubre que en realidad lo que buscamos de un auto es la libertad e identidad que nos proporciona, 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 información tratando de encontrar una palabra que define en la mente de los americanos situaciones como: sexo, trabajo, salud, etc. Lo que se me hizo realmente fascinante es que entre sus estudios se encuentran las definiciones 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 hecho de que el producto funcione, pero adicionalmente tiene que ver con la pureza y eficien-

10

MAY-JUL 2009

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 americana. 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 siempre 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 automotriz japonesa está en pleno auge liderado por Toyota. Los japoneses no sólo se preocupan porque el automovil funcione, sino cómo perfeccionar 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 ocurrido 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 fuera 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 calidad 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 vendedor esta es información muy importante. Un punto que no mencioné es que el americano valora mucho el movimiento, por lo que no puede asimilar la idea de la perfección, sólo Dios es perfecto. Ser perfecto implica ya no moverse, y solamente lo muerto no se mue-

ve, cero defectos implica ser perfecto. Así en las culturas occidentales no podemos hablar de cero defectos sino de mejora continua. No podemos aspirar a ser perfectos, pero sí a mejorar continuamente.

2) Si el occidental valora que las cosas funcionen entonces existe un gran valor en las áreas de soporte y de servicio. Si se descompone mi coche lo que quiero es que lo reparen inmediatamente aunque no tenga ningún plan de salir en él. Si mi programa de software 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 correctamente, 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 disciplina, 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 temperamento para lograrlo.

Es interesante entender estos rasgos culturales para así vender mejor nuestras ideas, y hacer de nuestras organizaciones la fuerza competidora que logrará en forma consistente los resultados que nuestros clientes están buscando.

Tomemos el reto, es hora de crear nuestra propia cultura de calidad. » Por Luis Cuellar www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

11

// PRODUCTOS

/* LO QUE VIENE*/

RubyMine

Por fin un IDE para Ruby

Moblin

Linux atómico Como evidencia de la popularidad que está cobrando el lenguaje Ruby, la empresa JetBrains lanzó RubyMine 1.0, un ambiente 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

Moblin es una edición de Linux optimizada para ejecutarse en sistemas basados en la tecnología Atom de Intel. La visión es proveer una plataforma completa para aplicaciones enriquecidas que aprovechen las capacidades de dispositivos tales como NetBooks, MIDs (mobile internet devices), sistemas de información/entretenimiento para vehículos, y otros dispositivos embebidos.

El proyecto se encuentra en etapas tempranas y todavía no está listo para producción, pero puede ser una opción atractiva para quienes estén considerando iniciarse en el desarrollo de aplicaciones para este segmento.

Más información en moblin.org

IBM WebSphere CloudBurst Appliance Habilitación de nubes privadas

Dryad y DryadLINQ

Procesamiento de datos en cluster 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 nubes privadas consisten en proveer recursos de cómputo y datos virtualizados 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 virtualizadas 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, administrados 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 Tivoli Service Automation Manager.

12

MAY-JUL 2009

Dryad y DryadLINQ son dos proyectos de Microsoft Research orientados a facilitar el procesamiento de grandes 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 clusters 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 integra con Visual Studio para facilitar el desarrollo.

Más información en: research.microsoft.com/en-us/projects/dryad research.microsoft.com/en-us/projects/dryadlinq www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

// PRODUCTOS

/*HERRAMIENTAS*/

Web Testing Utilizando Visual Studio Team Edition for Software Testers

Creando Web Tests de manera rápida, sencilla y eficiente Por Benjamín Ruvalcaba Con la llegada de Visual Studio 2005 Team System, Microsoft intentó crear un ambiente integrado de desarrollo de software en el cual todas las actividades del ciclo pudieran tomar lugar. Para satisfacer las necesidades de pruebas del desarrollo de software, Microsoft creó Visual Studio 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 implementar la herramienta en poco tiempo y sin los dolores de cabeza comúnmente asociados con el comienzo de la automatización de pruebas.

Creando web tests Ya que los web test solamente están disponibles en Proyectos Test, el primer paso hacia la creación de un web test es la creación del proyecto. Nótese que el tipo de proyecto Test solo existe como componente del Test Edition de Team System. Puedes agregar el proyecto 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: Generic, Web, Load, Manual, Ordered, y Unit. Selecciona Web Test y captura 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 requisiciones http que aparece bajo los controles de grabación.

Captura1. Creación de nuevo proyecto

Mientras estoy grabando actividad, entro a mi cuenta en el sitio utilizando 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 utilizan de manera subsecuente al primer uso en la grabación. Una vez identificados los parámetros dinámicos, el sistema ofrece la oportunidad de promoverlos para que sean utilizados en corridas posteriores.

Captura 2. Despliegue de la prueba y el árbol

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

14

MAY-JUL 2009

www.sg.com.mx

Al completar el paso anterior, el sistema despliega la prueba y el árbol de llamadas http(s). Este es el resultado de la grabación con los parámetros utilizados para mi acceso al sitio. Advertencia: La herramienta no utiliza encriptado. Por lo tanto, todo el tráfico es visible. Yo oculte mi clave para este ejercicio.

Con la integración de Team Foundation Server, podrías tomar los resultados y publicarlos para tener control de todas las pruebas ejecutadas. También es posible la creación de bugs mediante la utilización de estos resultados.

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

Agregando validaciones propias La herramienta agrega muchas validaciones propias. Asegura que la página se muestre, verifica que las redirecciones http que ocurrieron durante la grabación sean válidas al momento de ejecució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 validaciones posibles incluyen: Form Field, Find Text, Maximum Request Time, Required Attribute Value, Required Tag, y Response URL.

Captura 3. Prueba con validaciones

La validación de Form Field verifica que un campo en la página tenga el valor esperado. Un buen uso par esta validación se presenta en los campos defaults. La validación de Find Text verifica la existencia o inexistencia de determinado texto en la página. Yo lo utilizo buscando con la opción “fallar si encuentra el texto”, para buscar mensajes de texto comunes en errores de programación. Hay que recordar que la búsqueda solamente se hace a nivel HTML, así que puede haber texto embebido en la página sin ser visible.

Es posible tener mayor control sobre la creación de Web Tests mediante la utilización de Coded Web Tests. Estos son Web Tests que se crean y existen en código. Para crearlos se puede utilizar del botón designado o comenzando en blanco, haciendo uso de las programación utilizando las librerías de WebTesting que vienen con el paquete. También es posible programar extensiones al producto, tales como reglas propias para la extracción y validación del sistema.

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

Puedes definir cuánto es el tiempo máximo permisible para que cargue una página de tu aplicación. ‘Level’ es una propiedad comú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 carga. Como un bono, la herramienta de pruebas de carga (Load Testing) 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 informació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. www.sg.com.mx

Conclusión La creación de Web Tests utilizando Microsoft Test Edition es rápida, sencilla y eficiente. Debido a su dependencia en llamadas http e información HTML, es posible obtener resultados 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 Foundation Server. Al utilizarse apropiadamente, los beneficios que se pueden obtener con esta herramienta son muchos.

Espero la oportunidad de escribir más acerca de esto en artículos futuros.

Si tienes alguna duda o sugerencia puedes comunicarte conmigo en el correo benalonso@computer.org

MAY-JUL 2009

15

// PRODUCTOS

/*tutorial*/

Aplicaciones en la Nube con Azure Comprendiendo como funciona este nuevo esquema Por Miguel Angel Morán y Misael Monterroca

El cómputo en la nube o cloud computing es una de las tendencias que mayor impacto están teniendo en nuestra industria actualmente y hacia el futuro próximo. A pesar de que en el número 22 de SG ya se habló bastante sobre este tema, consideramos pertinente repasar algunos puntos, y aprovechar para familiarizarnos con Azure, que es la propuesta de Microsoft para una plataforma y sistema operativo para la nube.

Entendiendo la nube Desde hace mucho tiempo, en la iconografía utilizada dentro de los diagramas de topologías de redes, los trayectos donde viajan datos a través de internet se representan como nubes para enmascarar la complejidad del viaje a través de la red de redes. Derivado de esto, la nube es una alegoría de internet y representa precisamente toda la infraestructura que requiere internet para operar.

Cuando abstraemos este concepto e imaginamos la nube como una unidad y no como cada una de sus piezas (protocolos, conexiones, software, servidores, switches y un largo etcétera) tenemos el concepto al que actualmente se refiere la industria: Ver a internet como un todo, donde dejan de ser importantes los detalles exactos para que se logre echar a andar un aplicativo en internet, y conceptualizar a la nube como una constante, como una infraestructura de facto con la que podemos contar para utilizarla como plataforma de cómputo.

• Uso de estándares. Los estándares son importantes para lograr un ecosistema eficiente en la nube y una interoperabilidad maximizada.

XML, SOAP y últimamente REST son hasta el momento los estándares preferidos.

• Esquemas de pago basados en el consumo. Generalmente el software 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 disminuir la complejidad y los costos asociados al generar aplicaciones en Internet. Este concepto, a su vez hace uso de diferentes términos ya utilizados en la industria. (Figura 1)

Por lo tanto, podemos definir el cómputo en la nube como la utilizació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únmente aceptadas: • Tanto el hardware como el software son servicios. En los esquemas 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 administración de toda la infraestructura, desde el hardware, sistema operativo, base de datos. Si se desea escalar la aplicación es necesario 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 usualmente requieren de personal especializado, lo cual representa un costo.

En contraste, en la nube todo esto se ofrece como servicio y el proveedor se encarga de hacer todo esto de una manera automatizada, utilizando generalmente tecnologías de virtualización.

16

MAY-JUL 2009

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

Clientes. Son los dispositivos que consumen los servicios de la nube. Generalmente acceden a ellos mediante smart clients o páginas web.

Software como servicio. Se refiere a las aplicaciones de negocio en sí. Son las aplicaciones que los desarrollares crean y exponen a través de la nube. Es decir, cuando desarrollamos para la nube, debemos exponer nuestro software como servicio (comúnmente mediante web services y estándares web).

Plataforma como servicio: Se refiere a todo el software y herramientas 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. www.sg.com.mx

Infraestructura como servicio: Es como tal el hardware que el proveedor de servicios en la nube administra y facilita para el procesamiento 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.

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 consumible vía REST o SOAP expuesta en la nube.

• SharePoint Services: Otorga servicios de colaboración y personalización para ser usados en la nube.

• Dynamics CRM: Da acceso por medio de la nube a los servicios de Microsoft Dynamics.

Windows Azure Windows Azure es el sistema operativo para la nube que se ejecuta exclusivamente en los Dataservers de Microsoft. No es posible descargarlo ni instalarlo en un servidor local. Windows Azure proporciona abstracción de hardware, almacenamiento, monitoreo y actualizació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.

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

Las aplicaciones de negocio conforman el software como servicio (SaaS) que creamos específicamente para la plataforma Azure. Microsoft provee SDKs para diversas plataformas, como .NET, Java o Ruby que contienen ejemplos y todo lo necesario para desarrollar 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.

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 usuarios de Azure no tienen acceso directo al core de las máquinas virtuales sino que acceden al sistema operativo mediante los servicios expuestos por Windows Azure, mientras que Azure administra automáticamente todo el hardware (redes, DNS, almacenamiento, balanceo de carga, etcétera). Windows Azure además provee un servicio básico de almacenamiento basado en blobs, tablas y colas hospedadas 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 plataforma madura que ha sido ahora expuesta a los desarrolladores para su explotación.

Creando un “Hola SG”

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:

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.

• Live Services: Expone los servicios de Microsoft Live tales como identidad, comunicación, presencia, búsqueda, sincronización, ubicación geoespacial, etcétera.

En este breve ejemplo crearemos un web cloud service básico.

1. Iniciemos Visual Studio 2008 (si se desarrolla en Windows Vista o Windows 7, entonces es necesario ejecutarlo en modo administrador) 2. Dentro de Visual Studio 2008 seleccionar File -> New -> Project 3. En Project Types seleccionar “Cloud Service” y en los templates seleccionar “Web Cloud Service”.

• .NET Services: Proporciona bloques de código hospedados en la nube listos para usarse. Es como tener la biblioteca de clases del .NET www.sg.com.mx

MAY-JUL 2009

17

// PRODUCTOS

/*tutorial*/

protected void Page_Load (object sender, EventArgs e) { lblMensaje.Text = “Hola lectores de Software Guru”; }

7. Antes de realizar la depuración de nuestro sitio, es necesario establecer como proyecto de inicio el proyecto web (SGServicioEnLaNube_WebRole ). Finalmente realizamos la depuración de nuestro proyecto, presionando F5 nuestro sitio web será desplegado en nuestro navegador predeterminado, como cualquier otra aplicación ASP.NET

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

4. El template seleccionado, creará dos proyectos: SGServicioEnLaNube que básicamente contiene los archivos de configuración de la aplicación (las reglas que seguirá Azure para entregar el servicio) y SGServicioEnLaNube_WebRole que simplemente es un proyecto web tradicional (Asp.Net Web Project)

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

8. Mientras la aplicación se ejecuta, el systray muestra un ícono que representa al programa “Development Fabric” que es un emulador que simula el ambiente de hospedaje real de Azure, aunque lo hace de manera local.

9. Para hospedar el servicio en Azure, debemos publicar el proyecto y posteriormente seleccionar con el menú contextual “Browse to Portal”.

10. Esto nos llevará al portal de Azure en internet (es necesario registrarse previamente, y para poder publicar aplicaciones primero hay que obtener un token). Seleccionamos New Project y posteriormente Hosted Services Figura 2. Arbol de elementos del proyecto.

5. El siguiente paso será abrir la página asp.net creada por default y crear un control tipo “Label” al cual le agregaremos un mensaje desde el code-behind: <form id=“form1” runat=“server”> <div> <asp:Label runat=“server” id=“lblMensaje”></asp:Label> </div> </form> Figura 4. Publicando la aplicación en Azure.

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

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

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

18

MAY-JUL 2009

www.sg.com.mx

Conclusiones:

Figura 5. Escogiendo el ambiente correspondiente.

12. Como podemos ver, Azure muestra los servidores de staging (preproducción) y Producción. Al oprimir el botón Deploy el sistema 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 aplicación en la nube.

13. Posteriormente dentro del portal es posible promover el sitio de staging a producción.

www.sg.com.mx

La plataforma de servicios Azure provee una poderosa y efectiva solución para desarrollar, administrar y hospedar aplicaciones basadas en la nube, en cualquiera de sus capas (software, plataforma e infraestructura), es una alternativa real para generar aplicaciones escalables, interoperables y con alta disponibilidad reduciendo significativamente la inversión de tiempo y los costos. Proporciona además un ambiente amigable para los desarrolladores, aumentando su productividad derivado de los servicios “out of the box” que la plataforma ofrece.

Referencias: SDKs [microsoft.com/azure/sdk.mspx] Services [microsoft.com/azure/services.mspx] Herramientas de Azure para VS http:[is.gd/p3GV] FAQs de Azure [microsoft.com/azure/faq.mspx] Documentación para el desarrollo con Azure: [msdn.microsoft.com/azure]

MAY-JUL 2009

19

// ENTREVISTA

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

20

MAY-JUL 2009

www.sg.com.mx

¿En qué consisten tus actividades en TechBA? Básicamente tenemos tres actividades. La primera es estar en contacto con la industria y los medios para identificar problemas que pueden significar oportunidades de negocio. En base a eso, buscamos empresas mexicanas que potencialmente puedan proveer soluciones para esos problemas y hacer negocio. Por último, buscamos los recursos de inversión para habilitar el negocio en cuestión. Estos recursos pueden consistir en fondos de los distintos programas de gobierno, o también capital de riesgo. ¿Cómo ha sido la experiencia de estar en Silicon Valley?

Es un ambiente con características fabulosas. 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 necesariamente 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ápido). Es decir que si tienes una idea, la pruebes 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 amplia. Me he dado cuenta que es importante ver las cosas en grande, y que los negocios son para venderse, no para quedarse toda la vida con ellos. ¿A qué te refieres con que los negocios son para venderse?

Como empresarios debemos tener la actitud de decir: “yo voy a arrancar esta idea, la voy www.sg.com.mx

a llevar hasta donde llegan mis capacidades y esas capacidades van a tener que ser relevadas 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 millones 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éxico sean atractivas para capital de riesgo?

Justamente esa es la razón por la que empezó TechBA. La conclusión a la que hemos llegado 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. Tenemos que salir a vender no lo que se vende en México, sino lo que el mundo necesita en todos lados. El segundo punto es que debemos aprender a hacer un posicionamiento y diferenciació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 nuestro 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 generemos 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 problema 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 innovació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, generando 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 innovació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 programadores 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 proyecto Twirex (www.twirex.com), de una discusió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 tenemos una nueva idea o producto, la forma de mantener la ventaja competitiva es esconderlo de los demás. Esto es una pérdida porque al esconderlo le quitamos la posibilidad 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 enteres 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 mexicanos sino a personas de todo el mundo.

Es hora de alimentar nuestras propias motivaciones y transformar las inquietudes que todos tenemos dentro y que al liberarlas se conviertan en oportunidades invaluables donde podemos dejar nuestra huella y lograr nuestra realización personal.

MAY-JUL 2009

21

22

MAY-JUL 2009

www.sg.com.mx

Si eres uno de tantos desarrolladores 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 ancha, servicios de localización, plataformas multi-dispositivo y tiendas de aplicaciones en línea, el momento ha llegado para desarrollar aplicaciones para estos dispositivos y debes aprovechar la oportunidad.

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

www.sg.com.mx

MAY-JUL 2009

23

Un vistazo al pasado y presente del smartphone por Germán Domínguez

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

24

MAY-JUL 2009

Aunque los smartphones parezcan un ícono de apenas los últimos años, en realidad estos dispositivos tienen ya bastante camino recorrido. Conozcamos un poco sobre su evolución y cómo hemos llegado a lo que tenemos ahora.

Por otro lado, desde 1987 las comunicaciones celulares se activaron en México. En esos momentos 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 1983 Casio lanzó el PF-3000, que fue el primer “diario digital”. Esta era una calculadora digital que incluía capacidades para agenda telefónica, calendario y memo (notas).

En el 1992, IBM presentó el primer smartphone, conocido como IBM Simon Personal Communicator; vendido en Estados Unidos por BellSouth. Este dispositivo ya incluía capacidades de agenda, calendario, calculadora, correo electrónico, envío/recepción de fax, pantalla táctil y escritura predictiva. Era un dispositivo muy avanzado para su época.

www.sg.com.mx

El Apple Newton, lanzado en 1992, es considerado como el primer PDA (Personal Digital Assitant). De hecho, fue Apple quien acuñó este término para referirse al Newton. Este dispositivo contaba con un sistema operativo desarrollado en C++ e integraba funciones para envío e impresión de documentos, procesador de palabras, agenda, calendario y calculadora. Adicionalmente, permitía el desarrollo de aplicaciones personalizadas mediante un lenguaje de programació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, algunos 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 estandardizarse: todos deberían de incluir cuando menos agenda, calendario, bloc de notas y calculadora. Durante estos tiempos, el desarrollo de aplicaciones estaba basado en C; el IDE preferido para Palm era CodeWarrior de Metrowerks, un ambiente de desarrollo originalmente 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 Jornada. Estos dispositivos estaban basados en el sistema operativo Windows CE y tenían capacidades iniciales de 16MB de RAM, pantalla a color VGA y modem integrado. Las aplicaciones se desarrollaban en lenguajes de programación como Embedded Visual Basic (eVB) y Embedded Visual C++ (eVC) usando un ambiente basado en Visual Studio conocido como Microsoft Embedded Tools.

Los primeros esfuerzos para integrar comunicaciones inalámbricas en los PDAs se dieron a principios de esta década. En 2001, el Handspring Visor ya soportaba un módulo de extensió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 mercado los primeros dispositivos BlackBerry que incorporaban correo electrónico y telefonía celular. Esta capacidad integrada de correo electró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 plataformas y funcionalidades, durante este periodo los lenguajes de programación y ambientes de desarrollo para smartphones aumentaron significativamente. Surgen RADs (Rapid Application Development) para dispositivos móviles, el más destacado: Satellite Forms que permite el diseño visual de formas y pantallas para PalmOS y Windows Mobile. Los lenguajes tradicionales de desarrollo para dispositivos móviles se consolidan, 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 desarrolladores 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 incrementaban las capacidades de procesamiento y almacenaje. Palm produce nuevas versiones de Treo, algunas con el sistema operativo PalmOS y otras con Windows Mobile. HP tampoco incorpora grandes innovaciones, más allá de incorporar lectores de huella digital. BlackBerry 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, navegador Opera, radio y tonos polifónicos. Con esto se inicia una carrera entre los fabricantes de teléfonos celulares para brindar cada vez mayor convergencia en sus dispositivos. Por su parte, durante esta etapa los proveedores de redes celulares 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 primeras 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 cambiar 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 soportar 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. Asimismo, 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 descargas. Queda claro que el impacto de este modelo para ofertar aplicaciones. Tanto así que el resto de los proveedores, desde Microsoft hasta Research 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, Intel, eBay y otros que forman el Open Headset Alliance. Android está basado en el sistema operativo Linux y las aplicaciones se programan 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 lanzará el Palm Pre con el nuevo sistema operativo WebOS, en el cual las aplicaciones se desarrollan usando tecnologías sencillas y conocidas como HTML, Javascript y CSS. Aún hay mucho material adicional que cubrir, tecnologías, productos y nuevos lanzamientos. Pero al final nuestra labor como desarrolladores 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 buscado 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 germand@mx1.ibm.com

www.sg.com.mx

MAY-JUL 2009

25

Un modelo con alto potencial en aplicaciones móviles por Héctor Obregón

Hace varios años el concepto de aplicaciones peer to peer en Internet se popularizó y dio origen a una amplia variedad de soluciones 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) corriendo en dispositivos –la mayor parte de las veces una PC– que se comunican directamente 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 únicamente 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 direcciones de mis contactos de un servidor central que conoce las ubicaciones de todos. Sin embargo, una vez que inicio la

26

MAY-JUL 2009

llamada todos los datos de esta se intercambian 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-topeer “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 localizació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 implica 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 normalmente 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, resistente y prácticamente imposible de controlar por una autoridad central.

El escenario móvil

Hoy existen pocas aplicaciones móviles con un modelo de este tipo que verdaderamente aprovechen los diferenciadores de un dispositivo móvil. Es cierto que hay versiones móviles de Skype o Messenger, pero en mi opinión hay un amplio terreno sin explotar en aplicaciones móviles peer to peer.

Cuando hablamos de soluciones para movilidad, 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 hagan sentido.

La ubicación tiene dos connotaciones: 1. ¿Dónde estamos ubicados en el planeta? Definido por nuestras coordenadas – latitud, longitud y altura – obtenidas mediante alguna forma de posicionamiento – GPS, trangulación, etc. – 2. ¿Quién está cerca de mi? En este caso no es necesario conocer nuestra posición absoluta, el simple hecho de poder identificar qué es lo www.sg.com.mx

que está cerca de mí puede proveerme con información interesante.

Es en la convergencia del modelo peer to peer con la información de nuestra ubicación absoluta y relativa donde está el verdadero potencial de innovación en aplicaciones móviles. Pensemos en algunos ejemplos ...

Un automóvil podría comunicar a cualquier otro cercano que ha sufrido un accidente. Estos a su vez podrían retransmitir esta información a otros de tal forma que conductores que se acercan al punto del problema sean advertidos. 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 podría establecer contacto con la gente que está a mi alrededor comunicándole mis intenciones 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 espera en las colas. Esto último podría resolverse sin mayor interacción humana si los dispositivos simplemente analizan su densidad relativa en un área determinada.

Retos a resolver

Hay varios obstáculos que dificultan el desarrollo de este tipo de aplicaciones en este momento y que nos tocará ir resolviendo.

Diversidad de plataformas móviles. El mercado de dispositivos móviles es altamente competitivo y ningún jugador tiene una penetració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 conforme 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 seguido y en muchos lados. Si queremos crear una aplicación peer to peer de alto impacto seguramente tendremos que soportar a todas las principales plataformas móviles y este es un esfuerzo no trivial. El problema 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 mitigar este problema podemos dirigir nuestra 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 evolucionar de tal forma que sea más sencillo establecer 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 suficientemente 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 detalles 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 responder 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 control absoluto de con quién queremos compartir nuestra información. Resulta particularmente 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 control total sobre nuestra información al mismo tiempo que nos permitan compartirla de manera 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 hacer mientras las plataformas de los dispositivos 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 desarrolladores independientes pudieran agregar sus aplicaciones. Mientras tanto el ritmo de innovación dependerá de lo que cada fabricante pueda hacer por su cuenta.

Servicios estándar de descubrimiento geográfico. Necesitamos un DNS de descubrimiento geográfico. Un servicio totalmente estandarizado y abierto que me permita descubrir con facilidad 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 nombres 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 mucho más dispositivos móviles que computadoras en el mundo.

Por dónde empezar

Aún cuando los retos que hemos mencionado arriba son significativos, las herramientas necesarias 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 existe hoy para computadoras personales. Las principales plataformas móviles (Symbian, Windows Mobile, Blackberry e iPhone OS) todas 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 forma 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.

www.sg.com.mx

MAY-JUL 2009

27

Una interesante oferta para desarrollo móvil por Edgar Parada

Hace tiempo que observamos un fenómeno que consiste en una evolución de las aplicaciones 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 transparente. 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 modernos, 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 interacción con sus dispositivos mediante la disponibilidad de APIs y SDKs. Las principales plataformas tecnológicas para desarrollar software cuentan con ediciones y componentes específicos para dispositivos móviles. Asimismo, los ambientes de desarrollo modernos como NetBeans, Flash IDE y Visual Studio entre otros, ya cuentan con herramientas orientadas a facilitar el desarrollo en smartphones, tales como emuladores y perfiladores (profilers) de memoria.

En resumen, las aplicaciones móviles enriquecidas son un segmento que representa una gran oportunidad.

28

MAY-JUL 2009

Tecnologías para RIAs móviles

Existe un buen número de tecnologías disponibles para desarrollar aplicaciones móviles.

Las que tienen mayor tiempo y posiblemente 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. Personalmente, 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, quiero 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á liberada este verano, y la segunda es Silverlight for Mobile que se espera esté disponible con Windows Mobile 7 el próximo año.

Conociendo Flash Lite

Flash Lite consiste en una versión reducida de la plataforma Flash, diseñada para dispositivos móviles. Dadas sus capacidades y su ubicuidad, ésta puede ser una plataforma muy atractiva para quienes busquen desarrollar aplicaciones para dispositivos móviles. Adicionalmente, 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 recorrido. 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 impulsar 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 pareciera seguro impiden el rápido avance de las tecnologías emergentes. Una vez que Adobe adquirió Macromedia en el 2005 cambiaron la estrategia, buscando empujar Flash Lite por medio de los fabricantes de teléfonos móviles y encontrando una buena respuesta 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 primeros dispositivos con soporte a Flash Lite, y actualmente ya existe una gran oferta de dispositivos que soportan esta tecnología.

Más información: Project Capuchin tinyurl.com/5jypyc Kuneri Lite www.kunerilite.net Blocket PC Open Source: opensource.blocketpc.com SWX Format swxformat.org

www.sg.com.mx

Flash Lite actualmente se encuentra disponible en su versión 3.0. Su arquitectura consta de varios componentes que permiten a las aplicaciones y al contenido Flash interactuar con el ambiente local. El motor de rendereo de gráficas es capaz de interpretar imágenes en diversos formatos bitmap y vectoriales. También hay componentes específicos para el procesamiento de ciertos tipos de datos, imágenes, video, 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 Lite

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 adaptar contenidos a los diversos tamaños de pantallas e incluso cambios de orientación.

Proyecto “Capuchin” de SonyEricsson. Permite manejar la interfaz de usuario en Flash Lite mientras que la lógica de datos se programa con Java ME. Los datos se pueden transmitir bidireccionalmente entre Java ME y Flash Lite por medio de APIs especiales.

SWX. El formato de datos más simple para trabajar con Flash.

En base a las fortalezas y debilidades de Flash Lite han surgido diversos proyectos complementarios. Listo a continuación los que considero más significativos:

Kuneri Lite. Es una herramienta RAD para extender las capacidades de Flash Lite, proporcionando acceso a protección de software, timers, acceso al sistema de archivos, Bluetooth, Cámara, GPS y tonos DTMF.

Adobe mismo tiene proyectos para promover 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 empaquetamiento de las aplicaciones, y Adobe AppZone que es una plataforma similar a la AppStore de Apple para que los desarrolladores puedan comercializar sus aplicaciones.

Soporte a Flash Lite en nuestra región

En México y otros países de América Latina ya existe una buena oferta de smartphones con un buen soporte de Flash Lite. Mención especial merece el modelo N5800 recientemente liberado 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 posibilidades de desarrollo con esta tecnología.

Vale la pena mencionar que Flash Lite no solo es soportado en smartphones, sino también en otros dispositivos como el Nintendo Wii y el Playstation 3.

Para una lista completa de dispositivos que soportan Flash Lite les recomiendo revisar www.adobe.com/mobile/supported_devices

Conclusiones

Después de conocer todos los proyectos y características de esta tecnología es relativamente más sencillo identificar oportunidades 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 oportunidad 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. edgarparada@activ.com.mx

www.sg.com.mx

MAY-JUL 2009

29

¿Por dónde empezar?

Por Juan José Karam

Cumpliendo casi un año en nuestro País, el teléfono producido por la empresa de la manzana ha empezado a tomar fuerza a través de sus aplicaciones, tanto en el aspecto casual en el cual podemos encontrar aplicaciones para consultar la cartelera del cine, video juegos e incluso revistas digitales, hasta el entorno empresarial con lectores de noticias, manejo 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 tener 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 comienza 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 desarrollo para iPhone OS. Esta es gratuita y se puede descargar desde el sitio de Apple Developer Connection (developer.apple.com).

Aunque la plataforma de desarrollo nos proporciona un simulador de iPhone bastante confiable, es recomendable tener ya sea un iPod Touch o un iPhone.

Estar inscrito en el iPhone Developer Program Standard el cual nos permitirá instalar la aplicación en nuestros dispositivos, como también permite el acceso a la App Store como medio de distribución.

Conociendo la plataforma

Es importante conocer primeramente cuales son las características de la plataforma, desde el lenguaje de programación hasta los frameworks que se utilizan en el desarrollo de iPhone.

30

MAY-JUL 2009

Objective-C

Objective C es el lenguaje de programación utilizado para programar aplicaciones 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 últimos extendieron el lenguaje de varias maneras, por ejemplo creando los NeXTStep frameworks que preceden a Cocoa. Podemos entender a Objective-C como una extensió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 tienen sus orígenes en C o C++, la sintaxis de Objective-C puede causarnos confusión en un principio, como ejemplo podemos analizar 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 misma, las sintaxis son totalmente distintas.

Por lo tanto nuestra primera recomendació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 “ObjectOriented Programming with Objective-C” disponible en developer.apple.com/iphone donde se explican a detalle las particularidades del lenguaje.

Arquitectura

Para entender a grandes rasgos el funcionamiento del dispositivo, y más importante, cómo es que nuestra aplicación convive con el mismo, debemos conocer como funciona la plataforma y qué partes la componen. Similar al Mach Kernel encontrado en Mac OS X, se encuentra el componente más importante: el Kernel de iPhone OS. Encima de éste se encuentran diversas capas las cuales nos proporcionan los servicios que darán vida a nuestra aplicación.

Cocoa Touch Media Core Services Core OS Figura 1. Arquitectura del iPhone SDK

Core OS. Rodeando al Kernel, los drivers y las interfaces del sistema operativo, ésta capa nos ofrece la oportunidad de acceder a las características de bajo nivel como pueden ser las más importantes: hilos, 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 construidas en C, por lo que usarlas nos puede agregar complejidad extra.

Core Services. Ofrece los principales servicios que todas las aplicaciones utilizan de manera directa o indirecta. Esta capa es muy importante debido a que en ella encontramos los servicios de Acceso a Datos con SQLite, Seguridad, conexiones www.sg.com.mx

HTTP-FTP y soporte XML. Los frameworks mas importantes que la componen son los siguientes: Core Foundation. Brinda soporte para colecciones de datos, cadenas, bundles, manipulación de URL y streams, soporte multi hilos y conexiones por puerto y socket.

CFNetwork. Construido en C, nos provee de manera simplificada el uso de conexiones HTTPFTP, además de la resolución de Host DNS. Core Location. Una de las principales características de iPhone es la capacidad de saber en qué longitud y latitud del mundo nos encontramos. A través de este framework podemos averiguar esta información.

Media

Si tienes en mente un video juego o una aplicación con contenidos, ésta es la capa que www.sg.com.mx

más te interesa. Permite crear aplicaciones visualmente atractivas con pintado en 2D o 3D, animaciones, audio y video. Todo esto a través de los siguientes frameworks: Core Graphics. Contiene las interfaces de dibujo de Quartz 2D. Este motor de dibujo en vectores que también podemos encontrar en Mac OS X provee soporte para degradados, colores y transformaciones de coordenadas. Sin embargo, 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 principales se encuentran el grabado, mezcla y reproducción de archivos de audio. En él también se exponen las interfaces de vibración del dispositivo.

Media Player. Presenta el soporte para visualización de videos a pantalla completa. Entre los formatos soportados están mov y mp4.

Cocoa Touch

Es la principal capa para la construcción de aplicaciones, ya que provee la infraestructura necesaria para manejar desde la interacción del usuario y las vistas, hasta la internacionalización de nuestra aplicación. Principalmente se compone de dos frameworks: MAY-JUL 2009

31

UIKit Framework. Principalmente utilizado para el manejo de la aplicación, ventanas y eventos del usuario. También a través de él se interactúa con el acelerómetro y la cámara. Este framework es el más utilizado por todas las aplicaciones de iPhone.

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.

Foundation Framework. Encapsulando la funcionalidad expuesta por el Core Framework del cual hablábamos anteriormente, nos brinda de una manera más sencilla de manejar arreglos, cadenas, fechas, e internacionalización entre otras.

Interface Builder nos permite diseñar la interfaz 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 documentarnos correctamente acerca de un control a ser utilizado, debido a que algunos de ellos pueden requerir una implementación especial, como por ejemplo responder llamadas de algún delegado.

Las Herramientas

El iPhone SDK nos provee de distintas aplicaciones 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 continuo apreciaremos esta segmentación.

Xcode

Amigable y poderoso, este IDE nos permite administrar nuestro proyecto y los archivos que lo componen, compilarlos para ejecució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 permite ocultar lineas de código, por ejemplo métodos terminados o que no serán trabajados en ese momento. Esto además de las caracterí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 importante contar con un control de versiones.

Entre los soportados por Xcode se encuentran Subversion y CVS. Pero si eres fanático de Git encontraras varios Scripts y recetas creadas por la comunidad para poder trabajar con este repositorio de código fuente.

Para aprender a utilizar Xcode a profundidad, te recomiendo visitar su sitio dentro

Interface Builder (IB)

Al referirnos a Interfaz Gráfica, por ejemplo en Visual Studio con los Windows Forms podemos 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 referencia cuando desarrollamos en iPhone encontramos 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 interfaces y las conectamos a nuestro código.

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 comparació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 disponible en el Apple Developer Connection.

¿Donde empiezo?

A mi punto de vista uno de los mejores lugares para empezar es el iPhone Development Quick Start (tinyurl.com/dm4hrc). Éste es un tutorial muy completo y fácil de seguir donde paso a paso irás construyendo aplicaciones en base a lo que hemos leído en este artículo.

Consejos Finales

Identifica cual dispositivo es tu objetivo, ya que en base a eso deberás basar tus características. Como un buen ejemplo, el uso de la cámara únicamente será posible en un iPhone y no en un iPod Touch.

Respeta el manejo de la memoria del dispositivo, así evitaras que tu aplicación se cierre en la visualización de un documento importante 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.

Figura. 2. El Interface Builder

Instruments

Partiendo del punto en el que nuestra aplicació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

Usa los recursos del dispositivo de forma conservadora. A ningún usuario le gustará que la batería del dispositivo se agote rápidamente 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.

Juan José Karam es un ingeniero de software multidiciplinario enfocado en la arquitectura y desarrollo de alta tecnología para emLink. Es expositor en la comunidad CocoaHeads México (cocoaheads.org.mx) y devoto practicante de Scrum. juan.karam@thesharpcode.com

32

MAY-JUL 2009

www.sg.com.mx

Tomando ventaja de la transformación del mercado por Carlos Silva

Las empresas en México han encontrado en los desarrolladores de software locales soluciones de calidad mundial. El desarrollo de aplicativos hechos a la medida de las empresas 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 mercados puede alterar su posición de liderazgo o relativo retraso en la industria. Por ello, es necesario atender dos puntos críticos que me parece influirán de forma contundente en la definición del futuro mercado móvil.

La necesidad de diferenciarse

Puedo citar al menos cuatro estudios de prestigiadas casas de investigación de mercados 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 personal 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 estrategia 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 similar ocurra en el mercado móvil. ¿Qué estrategias seguir ante esta expectativa? Yo sugiero dos alternativas: 1. Enfocar los esfuerzos en desarrollar productos terminados. Muchas empresas en el mercado cuentan con algún motor básico de conectividad móvil y GPS que permite ofrecer “al cliente lo que pida”. Si bien esta es la estrategia correcta en un mercado inmaduro, 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 mayoría de los clientes con alto grado de configuración y ciclos cortos de implementación permitirá generar las economías de escala en la comercialización y despliegue que deberá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 especializada, extracción y servicios profesionales, entre muchas otras, siempre ofrecerán oportunidades para la especialización a las que difícilmente podrán acceder los proveedores que ofrecen aplicaciones genéricas.

La masificación de las aplicaciones móviles

El consumo hecho por individuos constituye 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 mayoritariamente se han enfocado exclusivamente al segmento de negocios.

De nuevo, esta estrategia ha sido la correcta, pero la apertura de las tiendas de aplicaciones de los principales fabricantes de teléfonos inteligentes, de la mano de las estrategias ya desplegadas por los operadores, representarán una gran oportunidad para acceder a un mercado enorme.

Recomiendo revisar estas consideraciones a toda empresa de desarrollo que esté planeando una estrategia de penetración del mercado de consumo: 1. El operador celular manda. Puede no gustar 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 operador 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 mexicanos 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 empresa 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 volumen 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 inevitables 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 csilva@rim.com y vía su blog personal www.csilva.net. Las opiniones expresada son suyas y no necesariamente reflejan las de RIM.

www.sg.com.mx

MAY-JUL 2009

33

// PRÁCTICAS

/*CASO DE ESTUDIO*/

Diseño de la Interfaz de SG Guía Detrás de las cámaras: Por Romeo Márquez

A inicios del 2009 el staff de SG nos presentó la posibilidad de realizar el diseño de interfaz para su nuevo proyecto: SG Guía, una herramienta 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 interfaz, mientras que la implementación en la herramienta de administració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 quieres echarle un vistazo para que puedas entender mejor este artículo.

La pre-producción Notamos una gran ventaja de trabajar con el equipo de SG puesto que tienen muy buenas prácticas de documentación de requerimientos. 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 diseñ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 plataforma de desarrollo para diseñar la interfaz de acuerdo a los requerimientos técnicos. Para este proyecto se seleccionó Drupal (www. drupal.org) y es parte de nuestra responsabilidad conocer las mejores prácticas de diseño para dicha plataforma.

Para crear una interfaz de usuario eficiente 1. Brief Creativo Este documento nos ayuda a definir las necesidades del negocio y los resultados deseados del diseño. El brief también ayuda a recabar la información relacionada con la identidad corporativa de la compañía, tecnologías a utilizar en el proyecto, listar requerimientos estéticos, proyectos competidores y dar un panorama general de los contenidos a publicar. SG fue muy específico en sus requerimientos por lo que desde un inicio, quedó muy clara la expectativa que teníamos que cumplir.

34

MAY-JUL 2009

2. Arquitectura de información Durante esta etapa, el arquitecto de información clasifica el contenido y busca crear un menú de navegación optimizado. El resultado que se obtiene es el mapa del sitio que será clave para la etapa de diseño.

En esta etapa es bueno realizar un benchmark entre proyectos similares para aprender e identificar los elementos que mejor puedan servirnos.

Un menú de navegación bien planeado es crítico para lograr una buena usabilidad ya que el usuario final no debe pensar demasiado para identificar donde podría estar la información que busca.

La SGuía originalmente contemplaba que las 4 categorías principales fueran 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 (representación sin elementos gráficos que muestran contenido y comportamiento de las páginas) de la portada e interiores ya que sirven como herramienta de discusión entre él y los programadores, diseñadores y cliente. Los wireframes son particularmente útiles durante la etapa de planeación ya que dejarán claro qué elementos se planean incluir en la interfaz.

3. Diseño gráfico Las dos etapas anteriores nos dan la suficiente información para que el diseñador realice la mejor interfaz posible totalmente orientada al público del sitio. En esta etapa el diseñador realiza también su propio 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 mostraban 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 elementos propuestos fueran viables técnicamente y que no hubiera alguna restricción técnica de Drupal para poder implementarlos. www.sg.com.mx

4. Maquetación Una vez aprobado el diseño, el equipo de desarrollo pudo entrar en acción para maquetar las plantillas de acuerdo a los estándares web, es decir, con XHTML, CSS. Adicionalmente, se integró jQuery al código, un framework de JavaScript que en este proyecto se utilizó entre otras cosas, para darle un movimiento específico a los íconos de portada.

5. Integración con Administrador de Contenido La integración del diseño con Drupal, fue ejecutada por el equipo de desarrollo de SG y gelattina apoyó proporcionando las plantillas y los elementos complementarios que la aplicación fue requiriendo.

6. QA & Testing La fase final previa a la publicación incluye la revisión del diseño buscando 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 testing 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 usability 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.

La prueba de la cajuela Durante las etapas de diseño y QA tomamos en cuenta la “prueba de la cajuela”. Lo que sucede es que solemos pensar que la navegación de un sitio empieza desde la página principal. Sin embargo, la mayoría de las veces los buscadores dirigen a los usuarios a partes específicas en el interior del sitio, por lo que es importante asegurarnos de que el visitante podrá ubicarse al llegar a cualquiera de nuestras paginas.

La prueba de la cajuela (trunk test) fue creada por Steve Krug y consiste 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 esenciales para facilitar no solo la navegación si no la interacción del usuario con nuestro sitio.

Conclusión La creación de un proyecto web, cualquiera que sea su tamaño, que busque ser exitoso requerirá de un buen trabajo de integración tanto en la parte tecnológica como en la interfaz del usuario. Para eso se requiere de un equipo multidisciplinario 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 combine el conocimiento de sus hábitos, mayor probabilidad tendrá 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 comentario 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, Cocacola, Banorte, Banregio, JackBe, Hoteles Marriott, ABA Seguros entre otros. Puedes seguirme en Twitter en @RomeoMarquez y @gelattina www.gelattina.com romeo@gelattina.com +52.81.8115.6150

www.sg.com.mx

MAY-JUL 2009

35

// PRÁCTICAS

/*MEJORA DE PROCESOS*/

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

Una auditoría de calidad a cualquier tipo de procesos de una organización se orienta a verificar cómo se desarrolla una cierta actividad de acuerdo a una norma establecida. La auditoría se apoya en una serie de documentos que definen 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 cuatro 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, comparando requisitos contra evidencias. Los productos de esta fase son los datos que sustentarán lo observado, mismos que se analizarán y categorizarán en desviaciones de la norma o hallazgos, 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 software Si los procesos de interés son los de la generación y mantenimiento de software, la auditoría de calidad se orienta a verificar si la organización cumple con los lineamientos establecidos en un modelo de calidad 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 determinar un nivel de madurez especificado en el modelo de software que se establece

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

de acuerdo a cómo se han implantado los procesos. Una consecuencia de la evaluación es sugerir mejoras que permitan alcanzar el siguiente nivel de madurez. Hay una retroalimentación explícita de resultados 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 requisitos prescritos en una norma o modelo, 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.

La metodología para auditorías de MoProSoft MoProSoft define documentos que describen lo que se debe auditar para cada uno de los procesos en las tres categorías: Alta Dirección, Gerencia y Operació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 lineamientos de implantación del modelo en una organización en particular. En la Tabla 1 se resumen los nombres y contenidos de los documentos para cada fase de la auditoría.

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

36

MAY-JUL 2009

www.sg.com.mx

FASE

NOMBRE DOCUMENTO Propósito de auditoría Alcance de auditoría Plan de auditoría

Preparación

Programa de auditoría Métodos de recolección de datos Ejecución

Informe de Auditoría Informe

Resumen General de Auditoría Cierre de Auditoría

Cierre

CONTENIDO 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 responsables 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*

Plan de Acciones Correctivas*

* Opcional, en su caso.

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

El Sistema MADAM Para facilitar esta metodología hemos creado el sistema MADAM (Manejo de Documentos para Auditoría MoProSoft) a través del cual se manejan 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 Auditoría para el proceso DIR. 1. Gestión de Negocios, donde el auditor debe llenar lo indicado en el Contenido para dar por concluida la auditoría.

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

Conclusión La metodología resulta de la aplicación de los principios de auditoría a la norma MoProSoft. Se siguen las fases prevalecientes en las auditorías para revisar los procesos considerando 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 mencionó el sistema asociado MADAM que maneja documentos adaptables para auditar a una organización.

Referencias [Arevalo-Cedillo, Leticia. “Auditoría y Evaluación de Calidad de Procesos de Software usando la norma NMX-059/01-NYCE-2005 MoProSoft”. 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/MoProSoft_sin_fronteras_mayo_2008_evento.pdf]

Leticia Arevalo Cedillo profesora de asignatura y actual Presidenta de Academia del Área de Docencia de Cómputo en la Universidad Autónoma del Estado de México.

Licenciada en Informática Administrativa egresada de la UAEMex y Maestra en Ciencias en Cómputo Aplicado del Colegio de Postgraduados. letyac@colpos.mx Jesús Soria Ruiz investigador del Instituto Nacional de Investigaciones Forestales, Agrícolas y Pecuarias, encargado del Laboratorio de Geomática del INIFAP en Toluca. Doctor en Ciencias por el Colegio de Postgraduados. soria.jesus@inifap.gob.mx

www.sg.com.mx

MAY-JUL 2009

37

// PRÁCTICAS

/*ASEGURAMIENTO DE CALIDAD*/

Medición y Análisis ¿Qué, Cómo, Cuándo?

Por Edith Alhelí Martínez

A lo largo de la definición e implantación de un programa de mejora, me he encontrado con temas que nos pueden “parar en seco” al momento de la ejecución. Uno de eso temas es el de Medición y Análisis cuyo objetivo, de acuerdo a CMMI es: “Desarrollar y sostener una capacidad de medida que es usada para apoyar necesidades de información de dirección”.

En general, cuando se llega al punto de definición de este proceso, no podemos avanzar o empezar a definir sin involucrar a más personal de la organización.

Lo que sucede frecuentemente es que el Responsable de Procesos (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 manera, ahora solo resta identificar qué es más importante, imprescindible, 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 establecer 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 servir de punto de partida o comparación (benchmarking), sin embargo 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.

Edith Alhelí Martínez Mata es Consultor especializado en temas de CMMI. Sus áreas de especialidad son el Aseguramiento de la Calidad, las Inspecciones de Software, los Procesos de Administración de Proyectos y Soporte. Ha participado como consultora en varios proyectos para implementación de CMMI a diferentes niveles, así como en evaluaciones SCAMPI. Alhelí estudió en el Instituto Tecnológico de Aguascalientes (ITA).

38

MAY-JUL 2009

www.sg.com.mx

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

8. Comprender que adoptar la práctica de medición implica un cambio de cultura que requiere esfuerzo, proactividad, adopción, seguimiento y actualización. A fin de cuentas, 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 enfocarse 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.

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 información de gran utilidad.

Para cerrar este artículo les comparto una frase que se atribuye a W. Edwards Deming, considerado el padre de la revolució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 Improvement Meaningful” ]

Figura 1. Gráfica de seguimiento a defectos

www.sg.com.mx

MAY-JUL 2009

39

// PRÁCTICAS

/*aRQUITECTURA DE SOFTWARE*/

El Valor de los Ciclos Guiados por la Arquitectura del Software Poniendo el enfoque en los objetivos de negocios y los atributos de calidad del producto Por Alejandro Bianchi

Si tuviésemos que precisar un atributo que defina al software en estos tiempos, seguramente muchos coincidirían en que la complejidad 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 interoperabilidad 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: desempeño, seguridad, mantenibilidad, etcétera. Estos atributos, reconocidos como “requerimientos no funcionales” o “atributos de calidad” son a veces la causa de importantes desvíos en el desarrollo o de serios problemas en la operación del producto, provocando insatisfacció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 complejo: múltiples equipos trabajando en diferentes lugares con diferentes 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 calidad ha contribuido en gran medida a mejorar la capacidad de producir 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 interpretació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 desarrollo 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 arquitectura como conductor del proceso de desarrollo, garantizando la calidad del producto y proactividad en todas y cada una de las etapas de fabricación e implantación.

40

MAY-JUL 2009

Una definición de arquitectura de software La arquitectura de un producto complejo de software es uno de los artefactos más importante del ciclo de desarrollo. Si bien sus principios y resultados han sido analizados, definidos y divulgados por un periodo de diez años, su práctica formal por parte de la comunidad profesional, es todavía vaga e imprecisa. Existen muchas 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 sistema 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 software es “un puente” entre las necesidades de los usuarios y los equipos 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 justificació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 involucrados (stakeholders) en el desarrollo del producto.

5. La arquitectura es la base para facilitar el reuso a diferentes niveles 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 posteriores del desarrollo.

Por último, la documentación de la arquitectura de software es el artefacto más importante que sintetiza el conocimiento acerca 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 formalizado. Muchas veces resulta común confundir diseño de detalle con www.sg.com.mx

“La arquitectura de un producto complejo de software es uno de los artefactos más importantes del ciclo de desarrollo”.

arquitectura. Los requerimientos no funcionales son poco considerados 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 software a partir de incorporar el proceso de diseño como componente esencial del ciclo de desarrollo.

Qué es un ciclo de vida guiado por la arquitectura Si bien no hay una definición consensada sobre lo que es un ciclo de vida guiado por la arquitectura, podemos decir que es un ciclo en donde los objetivos de negocios y los atributos de calidad del producto conducen el diseño de la arquitectura, y ésta es la base para la definición del resto del ciclo de producción y evolución a partir de: • Definir la estructura del proyecto (ciclos de vida, estimaciones, conformación de equipos, plan de comunicación, estrategia de configuration management, plan de pruebas, estrategia de integración e implantació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 siguientes puntos: 1. Los requerimientos analizan la funcionalidad y también definen, 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 identificados y aplicando patrones y tácticas elabora la solución técnica del producto, la cual se sintetiza en un documento de arquitectura, 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 despliegue 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 estrategia 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 Project Management). Por lo general, IPM es vista como la “tijera” que permite eliminar “lo que se necesita del proceso”. Pero si interpretamos 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.

Figura 1. Modelo de ciclo de vida guiado por arquitecturas

www.sg.com.mx

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 ciclos de vida guiados por la arquitectura. Son métodos prácticos que se sustentan en el uso de escenarios. Un escenario es una instancia concreta del uso del sistema y se compone de estimulo, elemento MAY-JUL 2009

41

// PRÁCTICAS

/*aRQUITECTURA DE SOFTWARE*/

estimulado, resultado esperado en base a mediciones y el ambiente en donde el escenario se produce.

La tabla 1 muestra los métodos, los roles involucrados y qué etapa del ciclo de vida soportan:

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 almacena, 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 sistema y mapas funcionales para identificar unidades de concurrencia 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 involucradas en construir, probar, mantener y evolucionar el producto.

• Deployment. Describe el ambiente en el cual el sistema será implantado, incluyendo las dependencias que el sistema tiene en tiempos de ejecución. Mapea cada elemento de software a otros componentes necesarios para que la ejecución esté de acuerdo a los requerimientos.

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

QAW es un taller (workshop) en donde se integran los diferentes involucrados 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ácticas 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, riesgos técnicos, conflictos entre atributos, puntos sensitivos del diseño y soluciones.

• 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 Software, Vol 12, nro. 6, 1995] [sei.cmu.edu/architecture/index.html]

Alejandro Bianchi es analista de sistemas, con un curso de postgrado en Sistemas Expertos de la Universidad Católica de La Plata y un diploma en Gerencia Estratégica de la Universidad Argentina de la Empresa. Socio y presidente de LIVEWARE Ingeniería de Software. Consultor internacional, con más de veintiséis años de experiencia en desarrollo de software, consultoría y administración de tecnología informática.

42

MAY-JUL 2009

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

43

// PRÁCTICAS

/*PROGRAMACIÓN*/

Programación Declarativa Conociéndola y entendiendo su aplicación real

Por Gastón Milano

Si al escribir un programa de cómputo lo que hacemos es explicarle a la computadora por medio de instrucciones detalladas “cómo hay que realizar una tarea”, entonces estamos programando en forma imperativa. Es decir, estamos alimentando los pasos o conjunto de instrucciones necesarias para resolver un problema. Por otro lado, si al escribir 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 necesarias para resolverlo. La programación declarativa es tan solo eso.

En realidad, la programación declarativa es un término que agrupa los siguientes paradigmas de programación: Programación lógica. Los problemas se representan por medio de lógica matemática.

“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 sentido, el qué perdura mucho más que el cómo.

Un primer ejemplo Veamos un ejemplo de cómo nos puede ayudar la programación declarativa. Supongamos un caso sencillo de un programa que suma los números del 1 al 100. Una posible solución procedural podría ser un programa similar al siguiente:

int suma = 0;

for (int i = 1 to 100)

suma += i;

return suma;

Una solución declarativa podría ser simplemente: suma = Sum(1, 100)

Programación funcional. Todo se resuelve por medio de la evaluació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 combinan la descripción de dependencias entre componentes, con instrucciones imperativas para compilar o instalar una aplicación.

Ventajas de la programación declarativa Cuando pensamos en los beneficios de programar en forma declarativa, en general se empieza pensando en las ventajas propias 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 programación declarativa consiste en que el indicar a la computadora

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 cosas 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 procesadores. Ya muchas computadoras están equipadas con tecnología de cuádruple núcleo.

Aquellos programas como el que hace la suma imperativamente, 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.

44

MAY-JUL 2009

www.sg.com.mx

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

Lenguajes declarativos Existen una gran cantidad de lenguajes declarativos. En el caso de los funcionales, entre los más populares están Scheme, Erlang, 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 programació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.

www.sg.com.mx

Conclusión Ahora, después de 20 años, los grandes de la industria comienzan a darse cuenta de los beneficios de programar en forma declarativa. Antes de su retiro de Microsoft, el propio Bill Gates aconsejó que “deberíamos estar haciendo 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 software nos demos cuenta que claramente debe existir un cambio de paradigma a la hora de programar.

MAY-JUL 2009

45

// PM CORNER

Revisión de la 4ta edición de la Guía PMBOK Cambios Importantes Por Jorge Valdés

El pasado 31 de diciembre de 2008, el Project Management Institute (PMI), publicó de manera simultánea la actualización de cuatro de sus estándares fundamentales. De ellos, el más importante y difundido es por mucho La Guía PMBOK.

La actualización de los estándares del PMI Los estándares reflejan prácticas comunes y un lenguaje universal para la profesión. Esto resulta en una mejor entrega de proyectos, incrementos en el retorno de la inversión y por supuesto, cuando son adoptados correctamente, una empresa más competitiva 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 busca alinear estos estándares fundamentales. Esto ayuda a asegurar que los profesionales de esta disciplina hablen el mismo idioma, incrementando el entendimiento.

Con ello, el PMI inició el proceso de armonización, incluyendo la evaluación de inconsistencias a lo largo de los cuatro estándares. Al final de lo que fue un largo y complicado proceso de revisión, los equipos participantes lograron estándares que no sólo están alineados sino que presentan la información de una forma clara y consistente.

Los cambios en la 4ta. edición de la Guía PMBOK La Guía PMBOK 4ta. edición se enfoca en la ejecución de un solo proyecto a través de los distintos grupos de procesos y establece una relación cruzada con las áreas de conocimiento.

Esta guía refleja la evolución del conocimiento dentro de la profesión de dirección de proyectos; la guía también refleja las prácticas 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 mejorada En general, la 4ta. edición refleja un enfoque centrado en mejorar 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 algunos párrafos explicativos para clarificar conceptos complejos.

Esto implicó una nueva redacción en todos los procesos, usando el formato de verbo en infinitivo más sustantivo. El uso estándar de verbos fue incorporado a todo el documento al describir conceptos recurrentes para facilitar el entendimiento.

Las descripciones de los procesos, que por cierto se repiten en cuatro lugares distintos, fueron re-escritos de manera más consistente a lo largo del documento. Los sitios donde podemos encontrarlos son: • Capítulo 3 • Al inicio de los capítulos de cada área de conocimiento • En la primera oración de la descripción de procesos aplicables • En el glosario.

2. Factores ambientales y activos de los procesos de la organización Se usó un enfoque estándar para discutir los factores ambientales y los activos de los procesos de la organización; es decir, mientras que en la versión 3 estos conceptos sólo se describían una sola vez, en la versión 4 se listaron en las entradas y salidas de cada proceso y se incluyeron descripciones específicas de cómo estos conceptos deben ser entendidos en cada proceso en particular.

3. Estandarización del concepto Solicitud de Cambios Otra área en la que se incluyeron algunas clarificaciones fue todo lo relativo a las solicitudes de cambio. En la 4ta. edición se incluye un enfoque estándar para discutir los cambios solicitados, las acciones preventivas, las acciones correctivas y la corrección de defectos. Todos 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. jvaldex@tenstep.com.mx

46

MAY-JUL 2009

www.sg.com.mx

cambios”. Esta revisión ayuda a racionalizar las entradas y salidas de gran cantidad de procesos, mientras que a la vez provee visibilidad de los distintos tipos de solicitud de cambios que pueden existir.

4. Procesos eliminados, nuevos y combinados Procesos eliminados En la 4ta. edición de La Guía PMBOK se borraron dos procesos: Desarrollo de la Declaración Preliminar del Alcance y Planeación del Alcance. En el primer caso, a decir del PMI, se tomó la decisión de eliminarlo debido a que ésta es sólo una forma de elaboración progresiva del acta de constitución del proyecto a la declaración de alcance.

La Planeación del Alcance fue borrada debido a que la salida de este proceso es el plan de administración del alcance, el cual es parte del plan de administración del proyecto así que no era necesario tener un proceso separado para tal efecto.

Procesos nuevos A esta versión se incorporan 2 nuevos procesos: Identificar Interesados y Recopilar Requisitos. Identificar Interesados se mencionaba previamente en la declaración del alcance. Sin embargo, 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 manera que una gran cantidad de proyectos inician con un tipo de recopilación de requisitos. Este proceso se añadió para reconocer esta situación.

Procesos Combinados Planeación de Compras y Adquisiciones y Planeación de los Contratos se combinaron en Planear las Compras. Solicitud de Respuestas 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 proyecto han sido diferenciados con mayor claridad. Esto se hizo con el propósito de destacar los planes subsidiarios y las distintas 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 incorporan en cada documento para reducir la repetición.

www.sg.com.mx

6. Reemplazo de diagramas de flujo de procesos por diagramas de flujo de datos Los diagramas de flujo de procesos de cada capítulo fueron reemplazados con diagramas de flujo de datos que muestran de dónde viene la información y hacia dónde va. Esto se hizo buscando mejorar el entendimiento en cuanto a la fuente de la información y su destino para cada proceso.

7. Complemento a la triple restricción La triple restricción, que había venido sobreviviendo a las distintas versiones y que era mencionada en la introducción de la tercera edición, ha sido extendida para incluir otras restricciones potenciales: calidad, recursos y riesgo. Sin embargo, dado que cada proyecto es único, es probable que no todos los proyectos se vean afectados por todas las restricciones potenciales.

8. Reconocimiento de la importancia de las habilidades interpersonales del gerente de proyecto Los gerentes de proyectos llevan a cabo el trabajo requerido a través del equipo del proyecto y otros interesados. Los gerentes de proyecto efectivos desarrollan un balance entre habilidades técnicas, conceptuales e interpersonales que les ayudan a analizar las situaciones y a interactuar de manera apropiada.

En la cuarta edición se agregó un nuevo anexo que describe las habilidades 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 interpersonales que deben usar los gerentes de proyecto, este anexo busca destacar las habilidades que, usadas apropiadamente, ayudan al gerente de proyecto a obtener los resultados más favorables.

Conclusión La Guía PMBOK es uno de los libros técnicos más vendidos en el mundo. Supongo que tiene varios méritos para ello. La actualización constante es uno, el otro es quizás que estas actualizaciones provienen de personas como tú y como yo, que han encontrado alguna forma de “más o menos hacer bien algo” en un proyecto y quieren compartirlo.

El mérito del PMI es, además de la visión que ha tenido para conjuntar estas prácticas, haber establecido los procesos que permiten que el documento evolucione y refleje las cosas que la comunidad de profesionales en esta disciplina, hemos ido aprendiendo a base de muchas cicatrices de guerra.

MAY-JUL 2009

47

// UML

Los requerimientos al estilo SysML Estándar Mundial Por Charlie Macías

Como ingenieros sabemos que cualquier producto derivado del proceso de diseño en ingeniería inicia de una declaración, por parte de un cliente, para resolver ya sea un problema 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 informales 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 profesamente 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 elementos que conforman al diagrama de requisitos definidos en la especificación de SysML e ilustraremos la aplicación de los mismos usando un ejemplo sencillo. Así mismo hablaremos de las distintas representaciones alternativas y aceptadas por la especificación.

El diagrama de requerimientos de SysML: principales elementos Requisito. Por supuesto el primer elemento que describiremos es el requisito. Un requisito está definido como un estereotipo de una clase UML sujeta a una serie de restricciones. Los requisitos estándar incluyen propiedades para especificar un identificador único y la descripción textual del requerimiento, sin embargo, el modelador puede agregar propiedades para definir, por ejemplo, la prioridad del requerimiento.

Relación de contención. La relación de contención vincula a un requerimiento complejo

con un conjunto de requerimientos contenidos 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 derivados con los requerimientos originales. Los requerimientos derivados, normalmente, son el resultado de aplicar un esfuerzo de análisis sobre los requerimientos originales.

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

Los requerimientos y la relación de contención: Dividiendo para vencer A continuación se presenta la descomposición del requerimiento original en sus requerimientos contenidos.

La declaración original del problema: ¿así o más claro?

Lo primero que podemos observar es la representación gráfica de los requerimientos. Estos muestran los atributos estándar para el identificador único (id#) y para la descripción textual (txt). Por cuestiones de espacio se ha omitido 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 requerimientos contenidos S1.0, S2.0 y S3.0.

Los requisitos y la dependencia derivada: soy, luego existo El siguiente diagrama ejemplifica el uso de la dependencia derivada. Supongamos que formamos parte del equipo de diseño al que se le ha encomendado la tarea de desarrollar un calentador de agua para uso residencial. Nuestro proveedor de requerimientos nos ha indicado que nuestro calentador debe ofrecer las prestaciones de un calentador a gas LP estándar, para uso doméstico, que da servicio a una familia 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 indicado que se debe favorecer el uso de fuentes de energía renovables y que el producto debe

Diagrama1. Descomposición del requerimiento original

Charlie Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado de sistemas y negocios con UML, BPMN y SysML. Puedes contactarnos en info@milestone.com.mx www.milestone.com.mx

48

MAY-JUL 2009

www.sg.com.mx

hemos descrito y ejemplificado en este artículo, SysML ofrece elementos adicionales para expresar ideas tales como las justificaciones de las deducciones (derivaciones) o el conflicto potencial entre los requerimientos, por mencionar algunos.

Así también soporta representaciones en formato tabular de los requerimientos, temas que abordaremos en el futuro.

Conclusión: El diagrama de requerimientos definido en SysML tiene la ventaja de haber sido creado ex profesamente para documentar los requerimientos y sus relaciones en un formato gráfico, sin estar vinculado a una metodología en particular. Los requerimientos poseen dos atributos estándar: el identificador único y la descripción textual. La relación de contención sirve para descomponer requerimientos complejos.

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 requerimiento S1.0) y D1.1. Si bien el requerimiento D1.1 no forma parte de los requerimientos originales, se puede derivar a partir de ellos.

Otros elementos para especificar requerimientos: Pero aún hay más

La dependencia derivada se emplea para incorporar requerimientos que se deducen a partir de los originales. Si bien en el presente artículo se ha empleado el diagrama de requerimientos de SysML para plasmar los requisitos de un producto de ingeniería que cae en los dominios de la ingeniería mecánica, su uso puede aplicarse a los dominios del desarrollo de productos de ingeniería de software. Recordemos que, finalmente, SysML está orientado 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.

Además de los conceptos elementales que www.sg.com.mx

MAY-JUL 2009

49

// COLUMNA

/*PROGRAMAR ES UN MODO DE VIDA*/

Evitando las Inyecciones de SQL Asegurando la validación de tus entradas Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.

E

n la edición anterior de SG prometí que en esta columna trataría temas relativos a la seguridad en cómputo y cómo escribir código más confiable y más robusto.

Las vulnerabilidades más comunes son también las más fáciles de explotar para un atacante (y utilizando algunas prácticas base, son las más fáciles de evitar o corregir). Casi todas las vulnerabilidades se originan por falta de validación (o exceso de confianza) en los datos proporcionados por el usuario.

Prácticamente, la totalidad de los sistemas web que desarrollemos procesarán datos provenientes de terceros: ya sea mostrando o grabando 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 «cloud 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 general, 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 capas 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» corresponda 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?

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 relacionados 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 sencillo 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 estrictamente. Como atacante, puedo buscar qué pasa si le pido al sistema algo que no se espere, por ejemplo «825aaa». En este caso (¡felicidades!), 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 motor de bases de datos supo reaccionar ante esta situación), pero estamos prácticamente a las puertas. Podemos generalizar que cuando 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

Enfoquémonos en el ID. Al analizar el URL, el ID es un pedazo de texto (formalmente es una cadena que es recibida como parte del método GET, uno de los métodos definidos para el protocolo HTTP). El servidor web Apache que recibe mi solicitud interpreta este método GET y en-

50

MAY-JUL 2009

La vulnerabilidad aquí consiste en que el programador no tomó en cuenta que $id_art puede contener cualquier cosa enviada por el usuario. ¿Cómo puede un atacante aprovecharse de esto? www.sg.com.mx

Presentaré a continuación algunos ejemplos, evitando enfocarme a ningún lenguaje en específico. Lo importante es cómo tratamos al SQL generado. Para estos ejemplos, cambiemos un poco el caso de uso: En vez de ubicar recursos, hablemos acerca de una de las operaciones más comunes: La identificación de un usuario vía login y contraseña. Supongamos 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ómoda y común de “interpolar” variables dentro de una cadena. Muchos lenguajes permiten construir cadenas donde se expande el contenido 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 comandos 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 terminada 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 consecutivo que concluyera de forma coherente, pero lo más sencillo es utilizar el doble guión indicando que inicia un comentario. De este modo, logramos vulnerar la seguridad del sistema, entrando 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 imaginemos el resultado de los siguientes nombres de usuario falsos: ninguno’ OR id = 1;-‘; INSERT INTO usuarios (login, passwd) VALUES (‘fulano’, ‘de tal’); -‘; DROP TABLE usuarios; --

www.sg.com.mx

Podemos ver un ejemplo similar en la famosa tira cómica de Bobby Tables (http://imgs. xkcd.com/comics/exploits_of_a_mom.png). ¿Y qué podemos hacer? Protegerse de inyección de SQL es sencillo, pero hay que hacerlo en prácticamente todas nuestras consultas, y convertir nuestra manera natural de escribir código en una segura.

La regla de oro es nunca cruzar fronteras incorporando 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 separar 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 parámetros a través de «placeholders», marcadores 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 índices para respondernos. Podemos enviar contenido arbitrario como login y password, ya sin preocuparnos de si el motor lo intentará interpretar.

Revisar todas las cadenas que enviamos a nuestra base de datos puede parecer una tarea tediosa, pero ante la facilidad de encontrar y explotar este tipo de vulnerabilidades, bien vale la pena. En las referencias a continuación podrán leer mucho más acerca de la anatomía de las inyecciones SQL, y diversas maneras de explotarlas incluso cuando existe cierto grado de validación. » Por Gunnar Wolf

Referencias: [en.wikipedia.org/wiki/SQL_injection] [ ferruh.mavituna.com/sql-injectioncheatsheet-oku/] [msdn.microsoft.com/en-us/library/ ms161953.aspx] [unixwiz.net/techtips/sql-injection.html] MAY-JUL 2009

51

// COLUMNA

/*PRUEBA DE SOFTWARE*/

El Modelo de Calidad Europeo TPI Aplicación en México de TPI, un Modelo de Calidad Especializado en Prueba de Software Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es cofundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

R

ecientemente invitamos a México a Martin Pol, reconocido gurú en Prueba de Software, fundador de Poltec (empresa holandesa de consultoría y certificación) y co-autor del modelo europeo Test Process Improvement (TPI), del cual plasmaremos aquí un breve análisis.

En la edición Agosto-Octubre 2008 realizá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

elementos clave a ser evaluados para medir la madurez en el proceso de pruebas de una organización.

Martin ofreció la conferencia magistral “Global Trends in Software Testing”en Guadalajara, Monterrey y el Distrito Federal.

En esta ponencia Martin comentó que probar un sistema de información no excluye al resto de los elementos acompañantes del software, como son el hardware, la documentación, los procedimientos, el material para el entrenamiento y la implementación, sino que éstos deberían ser probados tambié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 actividad 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 obtenidos marcados en rojo, esto nos permite asomarnos a lo que en México se está logrando dentro del área de Prueba de Software.

Atendiendo los conceptos manejados en TPI, podemos ver a éste como un modelo 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 comparamos contra otros modelos de calidad genéricos como CMMI, podrían ser categorizados como: Controlado (del 1 al 5), Eficiente (del 6 al 10) y Optimizado (del 11 al 13).

Figura 1. Categorías de madurez en TPI

52

MAY-JUL 2009

Para medir cada área clave, TPI contempla una serie de check points sobre los elementos que deben ser cubiertos; de acuerdo a www.sg.com.mx

clave, se asocian check points a cada una de dichas áreas, las interdependencias existentes entre ellas son indispensables para alcanzar 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 exitosamente implementado en organizaciones mexicanas, contribuyendo con ello a una mayor competitividad de la industria mexicana del software. La madurez del proceso de la organización que aplica las pruebas, es un factor importante en la madurez del producto que sale a un ambiente de producción y puede evitar importantes pérdidas ocasionadas por la liberación de software inmaduro.

Felicitación 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 obtendrá una calificación A si las estimaciones se obtienen utilizando argumentos sólidos; una calificación B si además de ello, las estimaciones se obtienen utilizando argumentos estadísticos, modelos matemáticos, automatizados. 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 posicionarnos en el nivel 10 para dicha área.Como podemos 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 calificaciones 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 aeroná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

Antes de despedirnos: en la edición anterior decíamos que en marzo tendríamos como invitado en e-Quallity a un experto internacional, con quien ofreceríamos pláticas sobre temas relacionados con los Modelos de Calidad Especializados en Prueba de Software en distintas ciudades; nos referíamos a las pláticas de Martin Pol que ya mencionamos. Queremos enviar un saludo a quienes con su entusiasta participació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.

www.sg.com.mx

MAY-JUL 2009

53

// COLUMNA INVITADA

Programación Orientada a Negocios El Paradigma de la Conciencia Financiera Por Marco Dorantes

¿

Cuál es la última moda en tecnología?, ¿qué nuevo estilo dictan las corrientes comerciales de nuestra distinguida y glamorosa 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 moviera en software? La lista de tendencias ha incluido categorías tanto de diseño y arquitectura como de procesos y productos.Lo interesante 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íamos nombrar como: “Programación orientada a finanzas” o “Programación orientada a valor de negocio”. Una tendencia que derive en un nuevo paradigma, en uno que responda 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.

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áctica es que si el diseñador de software sólo valora los aspectos técnicos y primorosos de la tecnología, tendrá resultados significativamente 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 ejemplo 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 diseñador de software, —muy entusiasta de la última moda tecnológica— determina:

Hoy en día, un programador de computadoras junto con cualquiera que decida aspectos de diseño y arquitectura durante la creación de software —dentro de un contexto de negocio— necesita contar con, al menos, el entendimiento básico de los términos financieros relacionados con dichas decisiones.

Esta es mi tesis en este artículo.

“...lo que el banco necesita desarrollar es un ‘framework’ de acceso para conectarse a dicha base de datos pues éste le va a aportar un sinfín de beneficios gracias a su gran flexibilidad proyectada y poder de extensibilidad que le permitirá acomodar una plétora de requerimientos futuros fácilmente, sin preocuparse más por volver a considerar diferencia 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 infraestructura 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...”

La razón filosófica de fondo detrás de dicha tesis es una de tipo ético, es decir, una que

¿En realidad este banco necesitaría invertir en el desarrollo de tal infraestructura apli-

cativa para acceso a datos?, ¿a eso se dedica?, ¿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 programador puede realmente disfrutar pasar una noche o un fin de semana programando y avanzando en su oficio, pero cabe la pregunta ¿es justificable hacer eso a cuenta del negocio del cliente o empleador?

Valor de negocio En el nuevo paradigma propuesto, la pregunta 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 noció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 sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod

54

MAY-JUL 2009

www.sg.com.mx

“Un programador de computadoras junto con cualquiera que decida aspectos de diseño y arquitectura necesita el entendimiento básico de los términos financieros relacionados con sus decisiones”.

El valor de negocio es por lo que existen las asociaciones, lucrativas o no. Está compuesto 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, responsabilidad ambiental, productividad, etcétera).

Cualquier cosa puede representar valor de negocio, la clave es que esté debidamente formulado como parte de un esquema cuantitativo con el cual se proyecta la sostenibilidad de dicho negocio.

En el ejemplo, si el banco aceptara la supuesta necesidad de desarrollar él mismo sus propias piezas de infraestructura aplicativa para acceso a datos, tendría entonces 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 documentado el efecto que tiene el nivel de inventario sobre el valor de negocio), (4) correr el riesgo de que todo ese tiempo y esfuerzo se derroche si al paso del tiempo no se entregan los beneficios esperados por causa de una deficiente administración de la complejidad en el desarrollo de ese tipo de componentes de infraestructura aplicativa.

Un objetivo móvil Lo único constante es el cambio. El valor de negocio entregado a través de software usualmente posee el peculiar rasgo de ser susceptible de indefinición y ambigüedad.

www.sg.com.mx

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 contrario, el negocio tiene que adaptarse o morir. 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-evolución solución/problema planteado ya por Frederick P. Brooks, Jr. (autor del clásico libro The Mythical Man-Month: Essays on Software Engineering) desde hace décadas.

El negocio necesita un proceso de desarrollo de software que sea capaz de seguirle el ritmo, 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 disciplina y que principalmente esté enfocado en atesorar los aprendizajes sobre la marcha. 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 costo de cambio no crezca exponencialmente.

Construyendo confianza Un paradigma de programación orientada a valor 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 colaboración y conjunción de personal de negocio y personal técnico— será capaz de entregar el valor de negocio en los términos requeridos.

La capacidad de entrega de valor de negocio implica tanto la capacidad del personal de negocio para escoger prioridades, especificar 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 entrega por estar construyendo cosas que no entregan valor de negocio hoy.

Una manera para construir dicha confianza 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 negocio se va dando cuenta de lo que realmente quiere.

Conclusión:

Las conclusiones, junto con un planteamiento más extenso de esta idea de programación orientada a valor de negocio, son desarrollados en el texto de un servidor: “Beneficios sostenibles y desarrollo de software. ¿Cómo obtener beneficios sostenibles por los servicios que incluyen desarrollo de software?

Parte I. El modelo adaptativo de desarrollo”, el cual está publicado en forma electrónica en la sección de artículos en línea del sitio web de SG. Los invito a que lo revisen y me hagan saber sus comentarios.

Referencias [Kuhn, Thomas S. “La estructura de la revoluciones científicas” ISBN 9681675991] [Denne, Mark.; Cleland-Huang, Jane.

“Software by Numbers: Low-Risk, HighReturn Development” ISBN 0131407287] [Poppendieck, Mary; Poppendieck, Tom. “Implementing Lean Software Development: From Concept to Cash” ISBN 0321437381]

MAY-JUL 2009

55

// COLUMNA

/*tendencias en SOFTWARE*/

El Fin de la Plataforma Tecnológica Rumbo a la masificación de aplicaciones Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.

Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter

C

on el título no me refiero a la desaparición del software, sino al enfoque más allá de la infraestructura. Hoy se han acuñado nuevos términos para nombrar polos de desarrollo de tecnología: Barcamp, Twestival, Palermo Valley, Tequila Valley, Santiago Valley, Unacamp, Super Happy Dev House… Todos ellos se refieren a un renovado espíritu emprendedor, buscando adaptar ideologías culturales y sociales en economías emergentes.

El futuro de la tecnología La tecnología es una actividad humana que satisface las necesidades de los usuarios. Las tareas para resolver estas necesidades pueden ser muy simples o bastantes complejas. Los avances tecnológicos permiten satisfacer necesidades de mayor nivel en la Pirámide de Maslow. Esto crea una espiral; al avanzar la tecnología, nuevos escenarios de necesidades surgen 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 cubrir eficientemente sus necesidades. Es indispensable un nuevo ecosistema 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 relación al uso de tecnología En los últimos treinta años hemos cambiado la forma de ver los datos y la información, ahora es usada como commodity. La tecnología está entrelazada en las actividades de la vida diaria. La transformación que estamos viviendo cruza las barreras socio-psicológicas y socio-culturales. 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). Estos 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, desde 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 observar 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 tradicional, tiene que ver con cuales servicios son más fáciles de consumir a corto plazo

La sociedad de la información En abril del 2008 hice algunas observaciones en mi blog sobre “Innovación social” (sn.im/enfbh ). Hoy se han materializado estos pronósticos 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, salud, seguridad,etc.

3. Integración latinoamericana: ¿Cómo nosotros, los ciudadanos, podemos unir América Latina?

Estas iniciativas están apoyadas por herramientas como Twitter, que juegan un papel protagónico en crear un “web de tiempo real” dando mayor dinamismo a los denominados “grupos de usuarios”.

Conclusión: El discurso tecnológico ha cambiado en la última década, no solo después de la re calibración económica o de los temas de ahorro de energía. Hay que entender el mundo actual y apostar a ser líderes de “la siguiente generación” de soluciones. La inercia “pesa”: El Web 2.0 ya tiene 5 años y continua siendo objetivo de muchos grupos emergentes. Usemos la tecnología para coordinarnos mejor y alinear el impacto total hacia América Latina.

56

MAY-JUL 2009

» Por Luis Daniel Soto www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

57

// fundamentos

Personal Software Process (PSP) Reducción de defectos y estimaciones más exactas Por Consuelo Jiménez

PSP representa una metodología o un marco de trabajo desarrollado en 1993 por Watts S. Humphrey. Lo importante al construir software es tener un proceso disciplinado para llevar a cabo el desarrollo e implementar mejoras para lograr resultados de calidad. Enfocada principalmente en el rol del programador, ayuda a que este ponga atención en aspectos de planeación, diseño, estándares y revisiones al detalle de lo que va realizando, registrando todo aquello en formas 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 metodología (ver figura 1).

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 relacionados al desarrollo de su programa.

Cuando codificamos directamente utilizando un IDE (Medio ambiente 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 estos errores deberían de ser descubiertos si revisáramos a consciencia 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 construcció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.

Figura 1. Flujo de Procesos PSP

Esta metodología esta apoyada por una herramienta computacional desarrollada por el Instituto de Carnegie Mellon, que genera una serie de registros con información valiosa para llevar a cabo la siguiente planeació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 dirigirse directamente a codificar el programa, en lugar de haber realizado 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í-

Tu productividad mejorará, los defectos antes cometidos serán minimizados 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é desarrollando y vaya a aplicar la metodología debe dominar el lenguaje 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 fundamental 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]

Ing. Ma. del Consuelo Jiménez Fernández, profesor asociado de la Universidad de Monterrey en el Departamento de Ciencias Computacionales desde hace 22 años, certificada en PSP developer y PSP Instructor por el SEI of Carnegie Mellon University, con maestria en informática administrativa, especialista en desarrollo de software educativo, calidad de software y metodologías de desarrollo de software.

58

MAY-JUL 2009

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

// TECNOLOGÍA

/*INFRAESTRUCTURA*/

Grid Computing La unión hace la fuerza Por Beatríz Ríos y Luis Joyanes

Mientras que la programación paralela se basa en el concepto de “divide 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” capaces de procesar cantidades de información inimaginable en una sola computadora, o incluso en un solo centro de datos.

Antecedentes

Funcionamiento El funcionamiento de un grid requiere de un middleware que asegure la comunicación transparente entre diferentes ordenadores repartidos en distintos lugares geográficos.

El segundo elemento es un motor de búsqueda que no sólo encontrará los datos que el usuario necesite, sino también las herramientas para analizarlos y la potencia de cálculo necesaria para realizar las operaciones.

Los primeros conceptos de grid computing se exploraron en 1995 con el experimento “I-WAY2”, en el que se usaron redes de alta velocidad para conectar 17 sitios en Norteamérica y habilitar una infraestructura para soporte de los laboratorios virtuales.

Por último, las tareas de procesamiento son distribuidos entre los nodos donde hay capacidad disponible, regresando los resultados integrados al usuario.

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 ordenadores repartidos en todo el mundo que ceden tiempo de sus procesadores, ciclos de proceso desocupados, para analizar señales buscando patrones inteligentes extraterrestres.

Como se podrán imaginar, algunos beneficios de este esquema son: • Alquiler de recursos • Amortización de recursos propios • Gran potencia de cálculo a precio bajo sin adquirir equipamiento • Mayor colaboración y compartir recursos entre varios centros • Creación de organizaciones virtuales • Negocios basados en proveer recursos

Características Un sistema de grid computing se refiere a aquel que: 1. Coordina recursos distribuidos que no están sujetos a un control centralizado.

2. Usa protocolos e interfaces estándar.

3. Proporciona calidad de servicio no trivial.

Beneficios

Las organizaciones virtuales habilitadas por grids

Grid y P2P

Foster, Kesselman y Tuecke, precursores del cómputo en grid, plantean 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 controlan el modo en que comparten sus recursos.

La unión de ordenadores que comparten ciclos de procesamiento no usados, cada vez aparece más claramente como una futura aplicación de Internet. 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 estructura de nodos más controlada y jerarquizada en centros científicos.

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 Avanzados en Informática por la Universidad Pontifica de Salamanca en Madrid. Ha trabajado en la Banca, en el sector de telecomunicaciones, en el desarrollo de sistemas para la empresa y en la docencia. Actualmente se encuentra realizando investigación para el desarrollo de su tesis doctoral en Tecnologías de la Información, Web 2.0, redes sociales, usabilidad y empresas 2.0.

60

MAY-JUL 2009

www.sg.com.mx

“Foster, Kesselman y Tuecke, precursores de la computación “Grid”, plantean la existencia de organizaciones virtuales (OV) como puntos de partida de este enfoque”.

Usos de la tecnología Grid • En Gobiernos y Organizaciones Internacionales: En respuesta ante desastres como: inundaciones, incendios, terrorismo, en planificación urbana, modelos económicos, etc.

• En el mundo de la Medicina: La unión de recursos tales como bases de datos administrativas, archivos de historias clínicas e imágenes 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 eeducació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 asistido por computadora utilizando simultáneamente recursos situados en muchos lugares. Otra consecuencia de la tecnología grid es la creación de organizaciones virtuales: individuos, instituciones y organizaciones que comparten un objetivo común y que para lograr alcanzarlo, eligen compartir sus recursos, lo que se traduce en un acceso directo a ordenadores, programas, ficheros, datos, sensores y redes.

Conclusiones La virtualización es una respuesta a la problemática de la optimización de las infraestructuras. En concreto, la virtualizació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 tecnología de virtualización de varios proveedores permite minimizar los costos de compatibilidad de programas, migraciones 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 optimizada, ciclos reducidos de puesta en marcha de aplicaciones y por lo tanto, menores costos de gestión en la infraestructura. El cómputo en malla requiere de nuevos modelos de programació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, localización y mantenimiento de los mismos.

Referencias [Eiguren, I. “Los pioneros del Grid” .(2008) ] [Fernandez, S. “El Grid al servicio de la e-ciencia”.CESGA 2007.]

[Fox, G.; Thomas, M.“Grid Computing Environments “, Community Grids Lab, Indiana: Indiana University, Austin: TACC, University of Texas, Feb 2003.]

[Joyanes, Luis. “CIENCIA 2.0: Hacia la Ciencia Web con la Web 2.0 y Web Semántica (nuevo paradigma en la I+D+i)” en Semana de la Ciencia de Castilla y León. Salamanca: Universidad Pontificia de Salamanca: 13 de noviembre, 2008. ] [astic.es] [setiathome.ssl.berkeley.edu/] [super.unam.mx/]

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

www.sg.com.mx

MAY-JUL 2009

61

// tecnología

/*gadgets*/ Esta sección es presentada por Geek www.geek.com.mx

Amazon

Kindle DX

Alienware

M17

Las portátiles de Alienware siempre se han caracterizado no sólo por sus vistosos diseños, sino también por su poder. La M17 es el nuevo modelo y la primera en incorporar la tarjeta ATI CrossFireX y el procesador Quad-Core Intel móvil. La llaman “la solución que la industria necesita”, 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 primer Quad-Core móvil, que ofrece desempeño y eficiencia con capacidades multitarea con una velocidad de más del 50% que las generaciones 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 almacenamiento 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 Bluray 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 AlienTouch; no hay manera de que algún intruso se meta con ella.

Después del lanzamiento de Kindle de 6.5” el año pasado, ahora Amazon decidió crecerlo tanto en tamañ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 puedes 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 posee capacidad rotatoria, por tanto te permite leer en horizontal o vertical, sólo es cuestión de moverlo y la pantalla se ajustará de inmediato (sí como un iPhone). Su memoria de 3.3GB permite almacenar más de 3 mil 500 libros que se pueden descargar desde Amazon sin necesidad de buscar hot spots ni utilizar una computadora. Hoy en día existen alrededor de 275 mil libros disponibles para descarga en Kindle que incluyen 107 de los 112 New York Times Best Sellers disponibles hasta el momento.

Firebox

R2-D2 Projection Alarm Clock

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

62

MAY-JUL 2009

www.sg.com.mx

INDEX

DIRECTORIO

Anunciante

Página

Alpha Consultoría Ciudades Digitales e-Quallity gelattina IDC Itera JPE Consultores Matersys Milestone Consulting NYCE Praxis SG 09 Conferencia y Expo SG Campus

39 59 51 43 63 19 45 2F,1 4F 3F 9 11 57

Sitio www.alpha-consultoria.com www.ciudades.gob.mx www.e-quallity.net www.gelattina.com www.idclatin.com/mexico www.iteraprocess.com www.jpeconsultores.com www.matersys.com.mx www.milestone.com.mx www.nyce.org.mx www.praxis.com.mx www.sg.com.mx/sg09 www.sgcampus.com.mx

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

MAY-JUL 2009

63

// CARRERA

/*REPUTACION DIGITAL*/

Reputación Digital Cuidado con lo que subes a la Web Por Fernando García

Hoy día, cuando necesitas buscar información, referencias o simplemente localizar personas lo primero que haces es tratar de encontrar esa información en algún “Buscador” de internet como Live o cualquier otro de los existentes. Esto ya es una práctica 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 supuesto 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 informació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 escribieron 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 empleo 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 pregunta obligada es: ¿Cómo dejar esa huella?

Afortunadamente hay numerosas formas de hacerlo, varias técnicas 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 elegir 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 necesidades 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, herramientas, 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 fundamentales “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 trato a mayor profundidad y para cada uno hay técnicas, métodos, herramientas y prácticas que ayudan a conseguirlos. En colaboraciones posteriores los trataré por separado.

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 impartido varias conferencias en México y el extranjero, juez en varios concursos de desarrollo, y prolífico blogger. Puedes seguirlo en blogs.msdn.com/mvplead, www.ferglo.com y @ferglo

64

MAY-JUL 2009

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2009

57

No. 24

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Mayo-Julio 2009