SG14 (Marzo-Abril 2007) by Revista Software Guru

• Análisis de Puntos de Función • Evaluación de Arquitecturas • Model Driven Development

Software Guru CONOCIMIENTO EN PRÁCTICA Año 03 No.02 • Marzo-Abril 2007 • www.softwareguru.com.mx

ESPECIAL

Un vistazo a la industria de software

[ ENTREVISTA ]

Mariana Pérez-Vargas Abriendo brecha

Equípate

Herramientas de Desarrollo

México, $65.00

Noticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

[ Fundamentos ] Ingeniería Web

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Arte y Diseño Dafne Ortega, Oscar Sámano, David Gutiérrez Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO. Colaboradores Jorge Palacios, Dora Luz González, Francisco Castrillo, Ariel Sucari, Marcos del Pozo, Luis Du Solier, Rigoberto Calleja, Ysalia Bautista, Aquiles Santana, Omar Gómez, Sergio Cedillo, Sergio Orozco, Luis Daniel Soto, Lacendi Nolasco, Noé Huerta, Juan Pablo Bernabé, Roberto González, Susana Tamayo, Emilio Osorio, Leonardo N’haux

Editorial Para clavar un clavo, podemos utilizar diversos instrumentos, desde un zapato hasta un martillo de metal con mango de grafito. El martillo nos da la mejor calidad y productividad, pero el zapato lo tenemos más a la mano. De la misma forma, para desarrollar software podemos usar desde algo tan sencillo como un editor de texto y un compilador de línea de comandos, hasta una suite de herramientas para el ciclo completo de desarrollo de software. El criterio de decisión es similar. Por un lado tenemos calidad y productividad, y por otro tenemos la disponibilidad. Es cierto que todavía es posible hacer buen software con tan solo un editor de texto, y un compilador de línea de comandos, pero sabemos que eso ya es más un arte que una profesión. Las características del desarrollo de software moderno –multiplataforma, con tiempos cada vez más cortos, requerimientos cada vez más complejos, y equipos de trabajo cada vez más distribuidos– hacen indispensable el uso de herramientas. En países de primer mundo, donde la productividad es prioritaria debido a los altos sueldos, existe un uso generalizado de herramientas. Desgraciadamente, en países como los nuestros, todavía encontramos muchas organizaciones que prefieren meter más gente, o tardarse más,

MAR-ABR 2007

o arriesgar la calidad, con tal de evitarse la inversión en herramientas. Este es un ciclo vicioso del que debemos salir, si es que queremos tener una industria de primer mundo. Aún así, el precio no es el único pretexto para no usar herramientas, ya que existen muchas opciones gratuitas y open source. Es aquí donde entra en juego la ignorancia, y esto también es algo con lo que debemos terminar. Es por todo esto, que hemos dedicado este número de SG a hablar sobre herramientas modernas para desarrollar software. Como de costumbre, esperamos que esta información les sea de beneficio y los ayude a crear mejor software. Agradeceremos sus comentarios, sugerencias y propuestas de participación en editorial@softwareguru.com.mx

Fotografía Gabriel González Ventas Claudia Perea Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Subscripciones Daniel Velázquez Contacto info@softwareguru.com.mx +52 55 5239 5502

Equipo Editorial ------------Fe de erratas: Recientemente nos enteramos de un error en la edición de Sep-Oct 2006. El pie de la foto que sale en la columna de Hanna Oktaba (página 9), debería decir “Visita a la Central Hidroeléctrica de Colbún con los profesores de la Universidad Católica del Maule, en Talca”. Agradecemos a nuestros lectores chilenos por la corrección.

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. 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: 042004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en febrero de 2007 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.

www.softwareguru.com.mx

contenido mar-abr 2007

EN PORTADA Herramientas de software

Estudiamos cómo es que las herramientas modernas asisten el ciclo de desarrollo de software.

Productos LO QUE VIENE 12 PHP 6, XQuery, ParaSoft SOATest, Compuware Quality Assurance Manager

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Tendencias en Software por Luis Daniel Soto

Mejora Continua por Luis Cuellar

Tierra Libre por Emilio Osorio

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

Un vistazo a la industria mundial de software

Entrevista Mariana Pérez-Vargas

www.softwareguru.com.mx

Prácticas ADMINISTRACIÓN DE PROYECTOS 34 Análisis de Puntos de Función. Parte 1. En este caso de estudio, revisaremos a detalle el proceso para estimar con function points. En esta primera parte, planteamos el caso a estudiar.

ARQUITECTURA 36 Evaluando la Arquitectura de Software En esta segunda parte, Omar Gómez nos explica cuatro métodos de evaluación de arquitecturas.

ESTRATEGIAS DE DESARROLLO Desarrollo Dirigido por Modelos

Sergio Cedillo comparte con nosotros este artículo donde se analizan las actividades requeridas durante un proyecto de MDD.

En Cada Número Noticias y Eventos CLÚSTERS UML Fundamentos INFRAESTRUCTURA REFLEXIONES

MAR-ABR 2007

04 06 44 48 50 56

// NOTICIAS

SolidWorks World 2007 Del 4 al 7 de febrero se llevó a cabo en la ciudad de Nueva Orleáns la conferencia y exposición SolidWorks World 2007, organizada por la empresa SolidWorks, proveedora de software de modelado 3D para ingeniería. SG estuvo presente para conocer más sobre como es que se desarrolla un software de tanta complejidad. Una de las conferencias que causó mayor expectativa fue la de Steve Wozniak, el genio que inventó la computadora personal y de paso fundó Apple en conjunto con Steve Jobs. Entre las sorpresas estuvo la aparición de Leonard Nemoy (Sr. Spok de Star Trek), quien causó sensación entre los asistentes, que en su mayoría eran ingenieros. También tuvimos oportunidad de platicar con el equipo de arquitectura y pruebas, en un futuro les estaremos compartiendo más información al respecto. Para mayor información visita: www.solidworks.com

CONSOL 2007 Del 13 al 16 de Febrero tuvo lugar en la Facultad de Ingenierías de la UNAM el Congreso Nacional de Software Libre, CONSOL 2007. En el evento se abordaron temas como: filosofía del Software Libre, desarrollo de software, aplicaciones, seguridad en redes, y robótica. En el evento también tuvieron presencia empresas de soluciones basadas en software libre. El congreso contó con la participación de personajes de talla internacional como Marcus Börger (desarrollador de la librería Standard de PHP) cuya platica mostró el panorama actual y futuro de PHP y Beatriz Busaniche (Fundación Vía Libre - Argentina) que nos hablo acerca de la Gestión Digital de Restricciones, entre otros especialistas. Con este evento México destaca el interés sobre temas del Software Libre ofreciendo una alternativa libre a los usuarios y ampliando el conocimiento en estas tecnologías. Para mayor información visita: www.consol.org.mx

PROSOFT publica reglas para 2007 Para el 2007 PROSOFT tendrá una aportación de 462 millones de pesos, 8 por ciento más que en 2006, estimando detonar inversiones estatales y de iniciativa privada por unos 1,380 millones de pesos. Entre sus objetivos están: apoyar 350 proyectos empresariales, generar 8 mil empleos, capacitar a 6 mil ingenieros, certificar la calidad de 60 empresas, e integrar al programa a estados como Nayarit y el Estado de México. Entre los cambios importantes en las reglas de operación está la integración de apoyos dirigidos a usuarios de TI, esto con el objetivo principal de impulsar la demanda. En los años pasados se había apoyado a proyectos sobre desarrollo de aplicaciones, pero se detecto que muchos de ellos no tenían un mercado específico, no tenían una demanda clara, por eso ahora se buscará apoyar directamente al usuario final. Cabe mencionar que para poder subcontratar desarrollos y servicios de TI, es requisito para la empresa proveedora tener el 80% de sus desarrolladores basados en México, además de contar con alguna certificación o evaluación de calidad. La administración pasada designó 760 millones de pesos, detonando una inversión de 2 mil 476 millones. Durante este sexenio se buscará superar esta meta. Para mayor información visita: www.software.net.mx

MAR-ABR 2007

www.softwareguru.com.mx

// EVENTOS

8 Marzo 2007

22 al 24 Marzo 2007

Centro Banamex, Cd. de México Info: www.sap.com/mexico/techdayy07 Tel: (55) 52651601

Centro de Investigación en Matemáticas (CIMAT) Hotel Real de Minas, Guanajuato, Gto. Info: www.cimat.mx/sitios/seissigma Email: seissigma@cimat.mx

SAP Technology Day ‘07

9 Marzo 2007

Seminario ¿Porqué y cómo invertir en la mejora de procesos de TI? Itera, Monterrey, N.L. Info: www.itera.com.mx Tel: (81) 8368-2409 Email: trainnorte@itera.com.mx

III Simposio Metodología Seis Sigma

19 al 20 Abril 2007

Gartner Enterprise Integration Summit Centro Banamex, Cd. de México Info: www.gartner.com/mx/appint Tel: (55) 5584 9370 Email: latin.america@gartner.com

12 al 16 Marzo 2007

25 y 26 Abril 2007

Tecnológico Superior de Huetamo, Michoacán Tel: (435) 556 2774 Email: escolaresitsh@hotmail.com

Centro Banamex, Cd. de México Info: www.idc-eventos.com Tel: (55) 5604 2663 Email: idc@simrel.com.mx

Tecnológico de Monterrey y NIIT firman convenio

Zacatecas obtiene certificaciones PSP

El pasado 22 de febrero se llevó a cabo la firma del convenio de colaboración entre el National Institute of Information Technology (NIIT) de la India y el Tecnológico de Monterrey, con el objetivo de fortalecer alianzas estratégicas y consolidar proyectos como: estancias profesionales en la India, extensión conjunta a América Latina por medio de Universidad Virtual, así como el diseño conjunto de los programas académicos de las licenciaturas en tecnologías de información y computación. Igualmente busca generar mecanismos de certificación en la currícula y el establecimiento de un parque tecnológico en el municipio de Atizapán. Este convenio es muestra del compromiso que el Tecnológico de Monterrey tiene con el desarrollo de las tecnologías de información en México.

En el marco de un evento organizado por la Secretaría de Desarrollo Económico de Zacatecas (SEDEZAC), el Dr. Watts Humphrey entregó 12 certificaciones en PSP a profesionales zacatecanos. Zacatecas busca propiciar y fomentar la capacitación de profesores de las diversas instituciones de educación superior en las metodologías creadas por el Dr. Humphrey, PSP y TSP. Este evento representa un punto culminante en el proceso de desarrollo de la industria de TI’s en el estado, al que le seguirá la adecuación de los programas educativos universitarios para incluir la formación de las próximas generaciones en dichas metodologías, para contar con un capital intelectual capacitado en estándares de calidad internacionales para el desarrollo de software competitivo.

1ra. Semana de Sistemas y Computación

IDC Web Security Conference 2007

Cega Software obtiene Norma Mexicana El pasado mes de febrero la empresa Cega Software, dedicada al desarrollo de software especializado y al desarrollo de firmware, alcanzó el nivel 1 de la Norma Mexicana de Software. Dicha verificación fue otorgada por el NYCE, después de un proyecto de año y medio de duración, en el cual Cega implantó MoProSoft con el apoyo de la consultora Innevo. Carlos Enrique Gutiérrez, socio y jefe de desarrollo, comentó: “Hace 4 años iniciamos con el esfuerzo de CMM, pero debido al tamaño de la empresa, nos dimos cuenta que implantar este modelo no era factible. Cuando conocimos MoProSoft se nos hizo muy interesante, sobre todo la parte de gestión, que hace mucha falta en las PyMEs”. Aunque Cega acaba de verificarse, ya comienza a obtener beneficios en sus procesos, en sus productos, y hasta en la percepción del cliente. Para mayor información visita: www.cegasoftware.com

www.softwareguru.com.mx

MAR-ABR 2007

// INDUSTRIA

/* CLUSTERS */

inteQsoft

Mente de obra para una mayor calidad de vida Querétaro es uno de los estados más atractivos del país por la calidad de vida que se tiene, derivada de su planeación urbana, crecimiento económico sostenido, altos índices de seguridad social y laboral. Gracias a esto, en los últimos años Querétaro ha logrado atraer importantes empresas nacionales e internacionales, y se ha convertido en uno de los estados de mayor importancia económica en nuestro país. Es en este estado donde surgió el cluster inteQsoft, una organización conformada por la industria de tecnologías de información y comunicación de Querétaro.

Integrantes Jorge Buitrón, Presidente del Consejo de este cluster de tecnología nos comenta: “Nosotros empezamos con 13 asociados hace poco más de un año, pero ahora estamos hablando de 43 asociados, entre los que están varias de las universidades más importantes del país, como el Tecnológico de Monterrey, La Universidad del Valle de México, La Universidad Autónoma de Querétaro y el Instituto Politécnico Nacional”. Actualmente, las empresas que componen el cluster generan más de 4,600 empleos de alto valor agregado y facturan más de 57 millones de dólares al año. Entre los integrantes del cluster podemos destacar empresas como: Sigma Tao, Vision Consulting, Microsiga, Impulse Telecom, Praxis, Kepler, Opalo Software, AxS Tracker, Resource IT y FASST. Las dos grandes áreas de especialidad en este cluster son desarrollo de software y los call centers. Esta última es una especialidad que no habíamos encontrado en otros clusters en la República.

Filosofía y Visión Uno de los aspectos que más llama la atención de inteQsoft, es que su visión no se concentra en ser los más grandes, los mejores, o los más innovadores, sino en que Querétaro sea el estado con la mejor calidad de vida. Obviamente, para ello hay que atraer inversión, generar empleos y proveer productos y servicios de calidad, pero lo que importa es que tienen claro el fin con el que están haciendo todo esto. Esto también se refleja en los comentarios del Ing. Buitrón: “Al cluster no le interesan los negocios, le interesa traer el mejor ambiente propicio entre todas las partes para despegar el sector. El cluster es una base creada con la figura de los hechos. No es una asociación con fines de lucro, lo que se busca es el esfuerzo conjunto de todos los interesados para el bienestar común”. Otro aspecto importante de inteQsoft, es la importancia que le da a la investigación. Su objetivo no es ser un centro de mano de obra, sino de “mente de obra” para crear tecnología vendible. Es por esto que tiene una fuerte vinculación con el Centro de Investigación y Desarrollo Querétaro de CONDUMEX (CIDEQ), el Centro de Física Aplicada y Tecnología Avanzada de la UNAM (CFATA), la Universidad Autónoma de Querétaro, el Instituto Tecnológico de Querétaro y la Universidad Tecnológica de Querétaro.

Fortalezas

cas en el estado de Querétaro, sumadas a capacidades que se han desarrollado a través de proyectos de propósito específico. Es así que entre las principales fortalezas podemos listar: • Empresas especializadas y con madurez • Recursos humanos calificados • Desarrollo industrial del estado • Proximidad geográfica con el Distrito Federal • Voluntad Política y fuerte apoyo del gobierno del estado • Cercanía con proveedores de alta tecnología • Instituciones de educación superior y centros de investigación

Servicios Entre los servicios que inteQsoft ofrece a sus clientes y asociados se encuentran: • Administración de proyectos • Gestión de trámites para la obtención de recursos • Consultoría especializada en T.I. • Coordinación y fomento de la competencia y cooperación empresarial

Proyectos y Resultados inteQsoft se ha consolidado con una inversión de 47.4 millones de pesos. Se han desarrollado 18 proyectos, con más de 49 empresas beneficiadas y la generación de 2,180 nuevos empleos. Al igual que en otros clusters de TI en el país, uno de los enfoques principales ha sido aumentar la madurez de procesos. Es así que actualmente hay 8 empresas certificadas o acreditadas en algún nivel de un modelo de procesos como CMMI o MoProsoft, y otras 11 en proceso de certificación.

Conclusión InteQsoft presenta una atractiva configuración derivada de la especialización de sus empresas y de los profesionales que en ellas se desarrollan. Esto, aunado a las magníficas condiciones del estado y de la ciudad de Querétaro, así como a la aliciente voluntad política de las autoridades queretanas, lo convierten en un cluster líder en nuestro país. Para conocer más, visitar: www.inteqsoft.com.mx

Las fortalezas de inteQsoft son una mezcla de condiciones benéfi

MAR-ABR 2007

www.softwareguru.com.mx

MAR-ABR 2007

// COLUMNA

/*TEJIENDO NUESTRA RED*/

COMPETISOFT

Colaborar para Competir 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. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

ace un año nació el proyecto COMPETISOFT, apoyado por el organismo Iberoamericano CYTED (Ciencia y Tecnología para el Desarrollo). “El proyecto pretende incrementar el nivel de competitividad de las PyMES Iberoamericanas productoras de software, mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base para establecer un mecanismo de evaluación y certificación de la industria de software”. 37 representantes de 13 países, 17 universidades, 4 empresas y 3 organismos gubernamentales, nos reunimos la primera semana de diciembre de 2006 en Buenos Aires, para revisar los avances y definir el plan para el 2007. La visión general del proyecto, presentada en la figura 1 (siguiente página), supone como puntos de partida los modelos y trabajos ya existentes, en particular: MoProSoft y EvalProSoft se escogieron como base. Durante el 2006, los grupos participantes trataron de enriquecerlos con aportaciones provenientes de sus países. En el 2007 se van a llevar a cabo los experimentos de adopción del modelo de procesos en empresas de varios países, bajo la asesoría de los académicos locales. Para asegurar la uniformidad de estos experimentos, vamos a capacitar a los asesores y, a las empresas a través de dos talleres: uno en España y otro en Colombia. Estos talleres estarán a cargo de nuestras expertas y coautoras de MoProSoft: Maria Julia Orozco y Claudia Alquicira, ambas de Ultrasist. Las experiencias recabadas servirán de base para generar la versión consensuada del modelo de proce-

sos, del modelo de evaluación y del modelo de mejora de procesos adecuado para las PyMES. La aceptación de MoProSoft como modelo base, con unas pequeñas modificaciones, se facilitó gracias a que también, fue elegido como base por el WG24 de ISO. Esto nos permite armonizar las propuestas de COMPETISOFT con las de ISO. Los perfiles que se van a definir allá, los podemos utilizar como guías para nuestro modelo de mejora y retroalimentar al WG24, con los experimentos en varios países. Aprovechamos la presencia de personas relacionadas con organismos de normalización de Argentina, Perú, Brasil y España, para animarlos a participar en WG24, para tener mayor apoyo. Ganas no nos faltan, lo que nos falta a todos, son los recursos para asistir a las reuniones. Para los próximos tres meses nos dividimos en dos grupos de trabajo. El primero, coordinado por la Dra. Raquel Anaya de EAFIT, Colombia, que se dedicará a generar guías para todas las fases del proceso de Desarrollo y Mantenimiento, así como reportes técnicos sobre el uso de algunas herramientas. El segundo grupo, coordinado por Francisco Pino, alumno de Doctorado de la UCLM, España, tendrá como objetivo definir las primeras actividades, para iniciar el proceso de mejora en una empresa, lo que llamamos: Despegue. Acordamos de manera unánime, que el “despegue” tiene que ser precedido por una fase de “concientizar” –como dirían los mexicanos– a las empresas. Y aquí empezaron nuestras “broncas”. Unos decían que lo correcto es: “concienciar”, otros que: “conciencionar”;

Figura 1. Visión general del proyecto COMPETISOFT

MAR-ABR 2007

www.softwareguru.com.mx

total que acabamos acordando la necesidad de crear un glosario multi-español-castellano, para tener las versiones de los modelos que sean entendibles en cada país. Para acabar con este pequeño pleito, decidimos cambiarle el nombre a esta fase por el de: “enamoramiento”. Todos quedaron felices, pero no sé si lo van a entender las empresas. :) El Dr. Mario Piattini, es el director del proyecto. Es quien se encarga de organizarnos, reunirnos, ponernos en orden y es, quien rinde cuentas –hacerlo en nombre de tantas personas no son “enchiladas”–. Su labor es fundamental. Tiene dotes inmejorables de un líder y, además, de manera sincera, le interesa apoyar a la gente de América Latina. Es un “productor” incansable de doctores de esta zona, y gracias a sus relaciones hemos logrado un proyecto de tanto alcance. A mí me toca velar por la parte técnica de todo el proyecto, y seguir la labor “evangelizadora” en los países que todavía lo necesitan. En la lista están: Costa Rica, Guatemala, Salvador, Uruguay y (!!!) España. La reunión de COMPETISOFT en Buenos Aires, fue enmarcada dentro del primer Foro Iberoamericano de Ciencia y Tecnología (FIBECYT). Tuvimos la oportunidad de escuchar la preocupación de los participantes, por la

poca importancia que se da en nuestros países a Ciencia yTecnología (generada en casa) y sobre el “divorcio” que tenemos entre Academia y Empresa –me suena, me suena...–. Nos hizo reír el Sainete Criollo del Inocencio Ricerca y Empresio Mandatori, de Roberto E. Cunningham. Es un diálogo que, de manera muy divertida, muestra la brecha entre el pensamiento de un académico y de un empresario. Lo que sí me dio envidia, es que en varios países Iberoamericanos tienen sus Ministerios de Ciencia y Tecnología, mientras que nosotros... Y, ¿qué les cuento de Buenos Aires? Es una ciudad muy europea. Se come rico, sobre todo las empanadas y las carnes. El vino tinto es barato y de primera, y los productos de piel, dignos de “shopping”. Además, en diciembre las temperaturas están muy agradables y, para mi sorpresa, los argentinos en Argentina son muy amables. No tienen nada que ver con los argentinos de chistes mexicanos. Por cierto, también en México vamos a hacer experimentos de COMPETISOFT. Se buscan “víctimas”. — Hanna Oktaba

// COLUMNA

/*MEJORA CONTINUA*/

Otro día, otro artículo (Re)Iniciemos

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.

ace ya más de dos años inició esta aventura en SG. Durante el primer artículo que escribí, una y otra vez me preguntaba, ¿Qué es lo que quiero lograr con estos escritos? ¿Cual va a ser el objetivo final? La conclusión fue muy sencilla: quiero escribir algo práctico que pueda ayudar a otros a iniciar proyectos de mejora en sus organizaciones sin importar el tamaño, quiero aportar aunque sea una cantidad mínima en mejorar la industria de software en México. Así pues, después de 14 bimestres, me gustaría que nos preguntemos ¿Donde nos encontramos? ¿Hemos mejorado la forma en que desarrollamos software? ¿Hemos avanzado con nuestros planes de mejora continua? ¿Son nuestras organizaciones, unidades o proyectos continuamente más eficientes? A todos ustedes que dijeron ¡Sí!, les doy mis más sinceras felicitaciones. Es por gente como ustedes que la industria del software en México ha crecido como lo ha hecho en estos últimos años. Sólo les pido que sigan adelante, y espero que lo que hemos platicado en este espacio les haya servido para ese propósito. Ahora todos aquellos cuya respuesta es negativa, ¿Qué paso? ¿Nuestros jefes no nos apoyaron?, ¿A nadie en su compañía le importa la calidad? ¿Nadie los escuchó? ¿Ustedes no escucharon a los demás? Definitivamente, como en todo, lo más difícil es dar el primer paso, así que mi petición hacia ustedes es: ¡A iniciar! ¿No saben por donde?, veamos, un paso a la vez. Uno de los modelos más famosos de calidad se conoce como el Ciclo Deaming. El Ciclo Deaming nos dice que toda estrategia de calidad inicia con una etapa de planeación, seguida por la ejecución de los planes, luego se comparan los resultados con aquellos que estábamos buscando, se hacen los ajustes necesarios y se vuelve a iniciar planeando las siguientes fases. Así pues, iniciemos de la misma manera.

MAR-ABR 2007

Do, Check, Act

Figura 1. Ciclo Deaming

Planeación 1. Definir un objetivo claro, que indique a donde queremos llegar. En mi experiencia, la principal causa de fracasos en esfuerzos de calidad, es que el objetivo sea demasiado amplio o demasiado vago; “Queremos ser la organización de mayor calidad en todo el mundo”, suena muy interesante, pero no es lo más apropiado para iniciar un proyecto. Elementos más específicos como “Vamos a estandarizar la forma que estimamos para obtener datos comparables” o “Vamos a reducir los errores en producción en 80%”, son mucho más aterrizados y fáciles de manejar. Lo más importante es: a) que la mayor cantidad de gente posible esté de acuerdo en que esto es un problema y se requiere hacer algo al respecto, y b) que la solución se encuentre dentro del alcance de los participantes. 2. Identificar quienes van a ayudar a hacer realidad esta visión. Nota que estamos diciendo quien va a ayudar, no quien debe de participar. Tiene que ser gente con influencia, que esté de acuerdo con la importancia de los objetivos y está del lado del cambio. 3. Escoger de 3 a 5 cosas críticas para lograr tu visión. Un freno muy común para toda propuesta de cambio tiene que ver con querer demasiadas cosas al mismo tiempo o demasiado rápido. Por eso son máximo cinco, y la idea es poder tener avances visibles en lugar de concluir actividades que no van a verse hasta dentro de mucho tiempo.

¡Pues ya esta el plan!, ¡Iniciamos el trabajo! Los problemas más importantes en esta fase son la carga de trabajo y el seguimiento al proyecto. Aquí lo más indicado es: a) Repartir el trabajo en forma equitativa, b) acordar apoyar a nuestros compañeros y c) darle seguimiento periódico al avance, ¿qué se esta haciendo?, ¿estamos avanzando?, ¿son los resultados lo que esperábamos? ¿hemos tenido el apoyo que esperábamos? Si la respuesta es positiva sigamos adelante. Si es negativa, entonces hay que encontrar la causa y actuar ¿Necesitamos involucrar más gente?, ¿necesitamos un proceso diferente?, ¿falta entrenamiento?, ¿recursos?, ¿qué tenemos que hacer para llegar a donde queremos? En estas fases, es indispensable tener claro los objetivos y un meticuloso plan de comunicación con los participantes. Entre más estén todos bajo el mismo entendido, más rápido se ejecutará el plan. Adicionalmente, aquí es donde paga haber escogido las actividades de mayor impacto. Entre más visible es el avance más motivación existe de seguir avanzando. Finalmente, se debe de revisar como todo esto afecta a nuestros planes para iniciar nuevamente el ciclo. Recuerden que la calidad y mejora continua no son metas, sino caminos a seguir.

Recapitulemos Ya lo dice el dicho, para iniciar hay que dar el primer paso, es mejor iniciar con pasos pequeños que no iniciar. Lo importante es tener una visión a largo plazo e iniciar el camino en la dirección correcta. No importa si lo que puedes hacer es a nivel organización, a nivel proyecto, o hasta nivel individuo. Lo importante es que se vea una mejora sostenible para con eso iluminar el camino. Las cosas que valen la pena se dan paso a paso. ¡Bien pues, iniciemos! —Luis Cuellar www.softwareguru.com.mx

// PRODUCTOS

/* LO QUE VIENE*/

Parasoft SOATest

Porque SOA también requiere ser probado

Quality Assurance Manager Monitoreo de procesos de QA

Compuware Corporation lanzó al mercado una nueva solución para soportar procesos de mejora de la calidad, denominada Compuware Quality Management. Este producto provee herramientas que soportan la implantación y monitoreo de procesos de aseguramiento de la calidad. Compuware Quality Management asiste a las organizaciones a implantar procesos de calidad repetibles, y establecer métricas para monitorear los proyectos. A través de un portal web, los gerentes de calidad tienen a su disposición un panel de control con reportes de estatus sobre las actividades de QA, los cuales se pueden navegar para encontrar mayor detalle (drill-down). De esta forma, pueden dar seguimiento a que los equipos de proyecto ejecuten de forma consistente los procesos para entregar aplicaciones de alta calidad.

Parasoft liberó SOATest 5.0, una herramienta específicamente diseñada para probar y asegurar la calidad, seguridad y confiabilidad de las aplicaciones orientadas a servicios. Una de las características principales de SOATest es su habilidad de analizar web services al nivel de la capa de mensajes, y generar una serie de pruebas unitarias en JUnit que capturan el comportamiento del sistema. Una de las grandes ventajas del desarrollo de aplicaciones bajo un esquema SOA, es el bajo nivel de acoplamiento. Como sabemos, la ventaja de esto es la flexibilidad y adaptabilidad. Pero una de las desventajas es la complejidad para probar aplicaciones de este tipo. Esto porque no solo es necesario probar a nivel de aplicaciones independientes, sino también a nivel de mensajes, que se deben probar en tiempo de ejecución en un ambiente distribuido simulado.Parasoft se ha enfocado en proveer una herramienta que resuelva esta problemática, y al parecer lo ha hecho exitosamente con SOATest 5.0.

Mayor información en www.compuware.com Mayor información en www.prosoft.com

XQuery 1.0 y XSLT 2.0

PHP 6

En enero de este año, el World Wide Web Consortium (W3C) publicó ocho nuevos estándares de la familia XML. Estas especificaciones proveen un puente muy necesario entre las bases de datos relacionales, y los documentos. Entre las principales especificaciones que se hicieron oficiales están XQuery 1.0, XSLT 2.0, y XPath 2.0.

PHP, uno de los lenguajes más populares para desarrollar aplicaciones web, está preparando su nueva versión, PHP 6, la cual verá la luz a finales de 2007. Al parecer, con esta versión PHP quiere quitarse el estigma de ser considerado como el lenguaje para hacer aplicaciones fácil y rápido, pero no para aplicaciones corporativas con altos requerimientos de estabilidad, seguridad y “mantenibilidad”.

Estándares XML aprobados por el W3C

XQuery es un lenguaje de consulta de bases de datos para XML. “El XQuery será un interfaz unificador para acceder a datos XML, así como el SQL lo ha sido para datos relacionales,” comentó Don Chamberlin, co-inventor del lenguaje SQL y uno de los co-editores de XQuery 1.0 Estas tecnologías ya estaban disponibles anteriormente como versiones preliminares, y no son algo totalmente nuevo para la industria. De hecho, el WC3 indica que ha recibido más de 150,000 descargas de implementaciones de XSLT 2.0. Sin embargo, el hecho de que por fin sean liberadas como estándares oficiales, acelerará su adopción.

MAR-ABR 2007

Finalmente orientado a objetos

Es así que uno de los temas centrales en PHP 6 es la orientación a objetos, ya que versiones anteriores de PHP no soportaban bien este paradigma. Adicionalmente, en PHP 6 también se elimina la compatibilidad con “malos vicios” que se acarreaban de versiones anteriores, tales como register globals, safe mode, zendze1, y soporte a bibliotecas obsoletas de freetype y GD1. Mayor información en www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html www.softwareguru.com.mx

ial d el Software

un d M

Un Vistazo a la I

a i r t s nd u

Hacia la Conformación de un Ecosistema Empresarial Por Dora Luz Gonzlez Bañales

Sin lugar a dudas, en la última década, el desarrollo de las tecnologías de la información ha llegado a impactar en forma directa o indirecta a prácticamente todas las actividades económicas y al quehacer cotidiano del ser humano. En el caso de la Industria del Software, la demanda de productos y servicios derivados de ésta tiene una de las tasas de crecimiento mundiales más altas de la actualidad, se espera que dicho crecimiento sea aproximadamente entre el 6 y el 10% en los próximos dos años [1]. Las tendencias en el sector indican que, un factor clave para lograr dicho crecimiento, será la conformación de lo que se ha denominado: el “ecosistema de la Industria del Software” [2], es por ello que en este artículo, se presentan algunas consideraciones generales sobre lo que ha sido la evolución del concepto de software, la clasificación de mercado del software y sus cifras globales, así como su vinculación con el concepto de ecosistema empresarial.

Ecosistema Empresarial El concepto de ecosistema empresarial (business ecosystem), es un concepto de planificación estratégica que surgió bajo este nombre en el trabajo publicado por James F. Moore a principios de los años noventa (Moore, 1993), concepto que ha sido ampliamente adoptado en los entornos de sectores de alta tecnología.

MAR-ABR 2007

En términos generales, se puede decir que un ecosistema empresarial es un sistema abierto, en permanente evolución, y en el que sólo sobreviven los que se adaptan a los cambios. En las economías abiertas, cada oportunidad de negocio está condicionada por clientes, competidores, canales, precios y productos. La “especie empresarial” necesita evolucionar y adaptarse a los cambios. Si se analiza un ecosistema empresarial, su evolución es como la evolución de las especies, donde se presenta un proceso de selección natural[3]: •Flujos migratorios y cambios demográficos: un nuevo entorno social. •Nuevos medios y formas de comunicar: una nueva audiencia. •Nuevos pensamientos y valores sociales: un nuevo consumidor. •Nuevas demandas y servicios: un nuevo mercado. Aunado a lo anterior, es de interés destacar algunas de las definiciones más representativas del concepto ecosistema empresarial. La definición de Moore [4] describe a un ecosistema empresarial como un grupo de empresas que operan a través de múltiples industrias y que trabajan de manera cooperativa y competitiva en la producción, servicio al cliente e innovación. Basándose en este concepto, surge un segundo enfoque de lo que debe entenderse por ecosistema empresarial, y ésta es la de Iansiti y Levien (2004:8) quienes argumentan que el uso de

www.softwareguru.com.mx

una analogía biológica para definir un ecosistema empresarial, se caracteriza por una gran cantidad de participantes que están indirectamente interconectados, y dónde dependen uno de otro para lograr una efectividad mutua y así lograr sobrevivir, y sus miembros tienen un destino compartido. Para Elisa Vuori [5], un ecosistema empresarial es una estructura dinámica, que está compuesta por empresas que están interconectadas, y en la cual, cada uno de sus miembros tiene diferentes roles. Las organizaciones participantes pueden ser empresas pequeñas, grandes corporaciones, universidades, centros de investigación, organizaciones del sector público y otros grupos. Por tanto, es esta diversidad, aunada a la complejidad del mercado de software, donde radicará el principal reto para la conformación de un ecosistema empresarial en la industria del software, tanto en ámbitos regionales como internacionales.

Clasificación de Mercado de Productos de Software Para tener una base de referencia con la cual dimensionar la complejidad de la conformación de un ecosistema empresarial en el sector del desarrollo de software, a continuación se presenta una clasificación representativa del mercado de software, de acuerdo a la oferta en dos planos de intersección: 1) El plano horizontal: que indica la forma en que se entrega el software. 2) El plano vertical: que clasifica al mismo, de acuerdo a su área de utilización o fin del mismo [6]. Clasificación horizontal por forma de entrega Esta clasificación determina que el software puede ser empaquetado o hecho a medida. Esto tiene como consecuencia las diferentes formulaciones y alcances en la forma de comercializar, cobrar, estructurar los canales de distribución, los servicios de soporte, actualizaciones, entre otros temas. a) Software empaquetado: un producto de software empaquetado responde a especificaciones de uso extendido aplicables a una industria o actividad en particular, dando al mismo un carácter universal para dicha industria o actividad. El software empaquetado es uniforme y se vende en forma masiva; su código es cerrado y no puede ser objeto de modificación por parte del cliente. b) Software hecho a medida: se refiere a la creación de un nuevo producto de software o modificación de uno ya existente para que responda a las especificaciones particulares de un cliente. Su có-

www.softwareguru.com.mx

digo puede ser abierto y ser objeto de modificación por parte del cliente o de quien desarrolla la aplicación.

Clasificación vertical por área de utilización o fin Para un mejor entendimiento de esta clasificación, hay que considerar la definición de alcance funcional, que se refiere al conjunto de requerimientos formulados por parte del cliente, con respecto a las necesidades de resolución operativa que debe aportar un software al negocio. La clasificación vertical establece una sub- clasificación para el software de aplicaciones empresariales. El software de aplicaciones empresariales: es un producto empaquetado, o a medida; de uso personal, orientado a resolver funciones de negocios de mayor complejidad, como ERP, CRM o aplicaciones de negocios específicos de misión crítica. En las aplicaciones empresariales hay dos grandes segmentos: el horizontal y el vertical. •El segmento horizontal, agrupa a todo software de aplicación empresarial aplicables a más de una industrial. Este segmento incluye software de back office, de planificación de recursos empresariales (ERP), de cadenas de abastecimiento (suply chain), colaborativos, de recursos humanos, así como software de ingeniería y software de front - office, como CRM. •El segmento vertical, agrupa software clasificado de acuerdo a la industria de aplicación. Contiene la resolución de la gestión central del negocio, contemplando aptitudes de acuerdo al dominio del problema de la industria. Así, existen aplicaciones verticales para manufactura, retail, sector financiero, etcétera.

Mercado del Software en Cifras La tecnología de la información, es una de las actividades de mayor crecimiento en el planeta. Según cifras de IDC durante 2003, ésta generó alrededor de 1,400,000 millones de dólares. La industria del software, tiene un valor de producción mundial anual que sobrepasa los 200 mil millones de dólares, constituyéndose así en el mayor componente de la Industria de la Tecnología de Información. De acuerdo con estudios de la Comisión Económica para América Latina (CEPAL), la tasa de crecimiento de esta industria en nuestra región en los últimos 12 años, se acerca al 13,4% acumulativo anual. Los mayores productores y exportadores de software se concentran principalmente en Estados Unidos, India, Alemania, Japón, el Reino Unido y Francia. Los mismos que dominan ciertos sectores de la oferta de software, sobre todo los segmentos de mayor tamaño

MAR-ABR 2007

y mayor uniformidad de requerimientos funcionales. Además, en Estados Unidos, Alemania y Japón se encuentran las 20 empresas más grandes del mundo. La mayor concentración de mercado la tiene Estados Unidos con un 40%, seguido de Japón con un 10%. El software operativo de sistemas, que es el que controla el funcionamiento de una computadora, participa en el mercado mundial con un aproximado de 61 mil millones. El software utilitario, que incluye todo el software de gestión y manipulación de datos, herramientas de diseño y desarrollo, tienen una participación aproximada de 43 mil millones. El mayor segmento es el software de aplicaciones, cuyo mercado rebasa los 100 mil millones de dólares al año.

La competencia en el sector En la competencia dentro de la Industria del Software se contempla con gran interés la posibilidad de aprovechar una de las modalidades de actividad económica que más ha crecido en los últimos años: el offshore, en donde la India sigue siendo el líder. El offshore, que en 2004 representó una práctica que cubría el 30% de toda la actividad en TIC, realizada por las empresas norteamericanas y europeas, ha crecido a una tasa anual de 25%. De acuerdo a un estudio de Forrester Research, se estima que el número de empleos, que serán trasladados desde Estados Unidos hacia otros países crecerá desde 27 mil en el año 2000, hasta 472 mil para 2015. Lo que buscan las empresas norteamericanas con el offshore es, fundamentalmente, bajar los costos de la mano de obra empleada en los servicios de IT [7]. En lo referente a mercados emergentes, los casos de China e India son los más sobresalientes. Como sabemos, México se ha planteado como objetivo, convertirse en el país líder de Latinoamérica para el año 2013, alcanzando un valor de la producción de 5 mil millones de dólares.

Tendencias en el sector de la Industria del Software Las tendencias indican que, así como en el año 2004 en la Industria del Software se destacó el offshore, en el 2006 se destacó el inicio de la conformación del complejo ecosistema de la Industria del Software, donde formará una parte importante la relación entre desarrolladores de software, clientes, proveedores (de contenidos y servicios) y socios comerciales. La dificultad de la formación de este ecosistema radica, principalmente, en que la industria del software es por naturaleza compleja, ya que existen infinidad de productos complementarios necesarios para desarrollar soluciones, así como procesos complejos de conformación de alianzas y establecimiento de estándares, trayendo con ello la necesidad de satisfacer las necesidades de numerosos y diversos interesados.

En lo que respecta a las tasas de crecimiento proyectadas para el sector, la tabla uno refleja los resultados de los últimos años, e incluye el estimado para 2007. Vale la pena mencionar que, los márgenes de utilidades (antes de impuestos), típicamente van del 12 al 32% , aunque en el caso de las empresas en México, este porcentaje está entre el 6 y 10% [8].

2003

2004

2005

2006

2007

2.0%

3.4%

4.2%

5.8%

6.8%

Tabla 1. Proyecciones de la tasa de crecimiento de la industria del software a nivel mundial [9].

Siguiendo con las proyecciones para el sector, de acuerdo a una encuesta aplicada en abril de 2006 por McKinsey & Company y Sand Hill Group a 100 ejecutivos del sector de TI, se estima que en el año 2008, el presupuesto de TI asignado a gastos de software crecerá en un 5%, representando así el 35% del presupuesto total de TI [10]. En resumen, los puntos más relevantes que arrojó esta encuesta fueron: •Del presupuesto total asignado al software, se estima que un 35% se invertirá en nueva iniciativas, un 24% en mantenimiento, un 16% en nuevas licencias, un 15% en distribución de plataformas comunes y aplicaciones middleware para muchos usuarios, 6% en capacitación y 4% en otras iniciativas. Las empresas entre 100 y 999 empleados son las que estarán invirtiendo más en nuevas iniciativas, mientras que las grandes empresas (más de mil empleados) parece que reducirán sus inversiones en nuevas iniciativas (licencias, mantenimiento y capacitación para su infraestructura existente). •Los canales de venta de software incrementarán la necesidad de construir relaciones y desarrollar soluciones a la medida. •Los vendedores de software de todos los tamaños necesitaran buscar nuevas alianzas y sociedades, para lograr llegar a una mayor cantidad de clientes que estarán en la búsqueda de nuevas aplicaciones y soluciones. •La industria del software necesita mejorar, y desarrollar productos más innovadores, más fáciles de usar y más baratos. Un 30% de los encuestados identificó a la innovación (nuevos productos) como una de las áreas que más necesitan mejorar, seguido muy de cerca por la facilidad de uso y costos más reducidos. Será la innovación la mayor fuente de diferenciación. •En lo que respecta a si el software debe ser considerado como producto o servicio, existe una tendencia a que sea servicio (54%) (Software as - a- Service delivery model).

Dora Luz González Bañales. Doctorando del programa Integración de las Tecnologías de la Información en las Organizaciones del Departamento de Organización de Empresas. Universidad Politécnica de Valencia, España, y profesora del Departamento de Sistemas y Computación del Instituto Tecnológico de Durango, México. E-mail: dogonbaa@doctor.upv.es doraglez@itdurango.edu.mx consultoría en mejora de procesos.

MAR-ABR 2007

www.softwareguru.com.mx

•Una de las ventajas competitivas más importantes será la agilidad para adaptarse a las condiciones de mercado, a los movimientos estratégicos de los socios comerciales y dar respuesta en tiempo a las oportunidades que vayan surgiendo.

Conclusiones El desarrollo del software es complejo por naturaleza, el alcance e impacto de sus aplicaciones son tales que, se puede decir que el software ya forma parte del estilo de vida del ser humano moderno, y que se ha convertido en un elemento crucial en la economía mundial, por tanto, el desarrollo y comercialización de software se convierten con ello en un sistema muy variado y complejo, que lleva consigo la formación de un ecosistema industrial que hereda la naturaleza compleja del software. Dentro de las tendencias que se marcan en la industria del software, se resalta la conformación de un ecosistema para este sector, a través del cual, se busca formar una comunidad donde sea posible el desarrollo de soluciones más que de productos, y lograr junto con ello el establecimiento de una relación entre los procesos y necesidades vitales de cada uno de sus miembros (desarrolladores, proveedores, clientes, aliados, socios, usuarios, gobierno, etcétera). La conformación de un ecosistema robusto y funcional dentro de la industria del software no es, ni será, tarea sencilla. Quizá uno de los elementos que hace más compleja esta conformación sea el hecho de que el desarrollo y uso de aplicaciones de software son al final de cuentas, más un asunto de personas que de tecnología, esto es, el software no es sino la expresión de un comportamiento, de un deseo, de una necesidad que puede representarse a través de un programa de software, es por ello que en la constitución de un ecosistema de la industria del software, deberá lograrse la conformación de un sistema de relaciones y colaboraciones para desarrollo, comercialización, investigación y desarrollo, entre otras, entre clientes, proveedores, aliados, socios de negocio y competidores de todos los tamaños. Esto es, lograr la mayor inclusión posible de participantes en ecosistema de la industria del software, donde el primer paso será identificar a sus actores, sus roles y sus relaciones.

Referencias Bibliográfica 1. Sandhill (2006a). Industry Report. Proceeding: Software 2006. En: SandHill.com (Ed.), Conference: Software 2006, Unifying the Ecosystem, Santa Clara, CA. 2. Messerchmitt , David G. & Szyperski, Clemens (2003). Software Ecosystem. The Massachusetts Institute of Technology Press, U.S.A. 3. www.4reasons.com.es/ - Consultado 26/jun/2006 4. Moore, James F. (1993). “Predators and Prey: a new ecology of competition.” Harvard Business Review, May-June pp: 75-86. 5. Vuori, Elisa (2006). Intellectual capital in a business ecosystem. (Rep. Núm.: 123). Institute of Business Information Management. Tampere University of Technology, Finland. 6. PROARGENTINA. (2005). Industria del software. El Cid Editor. Serie de Estudios Sectoriales. 7. Hualde, Alfredo and Gomis, Redi (2004). “La construcción de un cluster de software en la frontera noroeste de México”. Revista Frontera Norte, México, Vol. 16, Julio-Diciembre, No. 32, pp: 7-34. 8. González-Baáles, Dora Luz (2006). “Industria Mexicana del Software. Un estudio en cifras.” Software Guru, Mayo-Junio pp: 16-18. 9. SIIA (2005). Packaged Software Industry Revenue and Growth 2005 Software & Information Industry Association. 10. Sandhill (2006b). CIO Insight Survey. Proceedings 2006. En: SandHill.com (Ed.), Conference: Software 2006, Unifying the Ecosystem, Santa Clara, CA.

www.softwareguru.com.mx

MAR-ABR 2007

Mariana Pérez-Vargas Abriendo Brecha

Prácticamente todas las organizaciones de software en México están interesadas en mejorar sus procesos, y posiblemente evaluarse en algún modelo de madurez. Continuamente nos enteramos de organizaciones que inician proyectos de mejora, y de los resultados positivos que tienen. Sin embargo, las cosas no siempre fueron así, y no hay mejor testigo de esto que Mariana Pérez-Vargas. Mariana es Directora General de Avantare Consultores, candidata a SCAMPI Lead Assessor, y es sin duda una de las personas que más camino ha abierto en el área de mejora de procesos en México. A continuación presentamos un poco de su historia y opinión sobre el momento que estamos viviendo en la industria de software.

MAR-ABR 2007

www.softwareguru.com.mx

// ENTREVISTA

Cuéntanos un poco sobre tu trayectoria. Soy Licenciada en Informática de la UNAM. Al salir de la escuela trabajé tres años en Banamex, y después de eso me incorporé a Tecnosys, donde fui parte del grupo de calidad que llevó a la empresa a certificarse en CMM3 en 1999. En el año 2000, me salí de IBM (que ya había comprado a Tecnosys) junto con otras personas, y formamos Avantare.

ahí MoProSoft no tiene reconocimiento, ¿entonces para qué me voy por ahí?”. Pero yo creo que un modelo no es bueno nada más por el nombre. Lo que importa es el cambio que se da en la organización. Además, no es necesario aplicar MoProSoft puro, sino que es posible combinarlo con elementos de otros modelos, para satisfacer los objetivos y necesidades de cada organización. Esta es una de las áreas donde un consultor de procesos puede agregar valor.

¿Qué problemas tuvieron para arrancar su empresa? Cuando empezamos, solo éramos dos las empresas en México que hacíamos mejora de procesos, era algo que no se conocía. Así que el principal reto fue hacerle ver a las organizaciones la necesidad de mejorar sus procesos de software. Los dos primeros años fueron muy difíciles porque tocábamos puertas y decíamos: “mira, es muy importante que cuando desarrollas software lo hagas en base a procesos, para mejorar tu calidad”, y la respuesta que nos encontrábamos era: “¿Procesos? No, para qué, así estamos bien”.

¿Qué sugieres que se haga para dar mayor difusión y credibilidad a MoProSoft? Yo creo que se necesita a algún organismo que sea el dueño de MoProSoft. La industria no puede ser el dueño, porque hay intereses particulares. La academia tampoco puede ser, porque no está suficientemente vinculada a la industria. Yo creo que debería haber una organización que haga en México lo que hace el SEI a nivel mundial, que sea un organismo rector e imparcial que esté ahí para el desarrollo y difusión de MoProSoft, que sea el que acredite a los evaluadores, y a los proveedores de servicios. Esto sería de gran beneficio para todos.

¿Qué hizo que cambiaran las cosas? Cuando Tecnosys se certificó, otras empresas competidoras comenzaron a hacer lo mismo, y eso generó un efecto en cadena entre las empresas medianas y grandes. Sin embargo, las empresas pequeñas seguían marginadas. Fue entonces, en el 2001, que nos invitaron a participar en la mesa de trabajo de PROSOFT que estaba dedicada a elevar la capacidad de procesos de las empresas. Aquí tuvimos discusiones muy largas, porque cada uno de los integrantes sugería un modelo diferente, y no lográbamos ponernos de acuerdo, hasta que se decidió crear un modelo mexicano (lo que hoy es MoProSoft). Nosotros apoyamos la creación de este modelo, y asignamos a una persona como editora de tiempo completo. Creo que los esfuerzos que se hicieron en esta mesa de trabajo han rendido frutos, ya que PROSOFT es lo que ha provocado el verdadero despegue en calidad a nivel industria completa. Sin este programa, las organizaciones pequeñas difícilmente estarían actualmente interesados, ni tendrían los recursos para elevar su madurez de procesos. ¿Cuál ha sido el efecto de PROSOFT en esta área? Creo que PROSOFT ha hecho dos cosas muy buenas. Por un lado, ha evangelizado y despertado el interés en mejorar, y por otro, ha apoyado con recursos económicos que son de especial ayuda a las pequeñas empresas, que de otra forma no podrían financiar proyectos de mejora. Un efecto de PROSOFT que no es del todo positivo, y que desgraciadamente se ha dado, es que se presta a que las empresas sólo busquen el papelito de certificación, sin preocuparse realmente por mejorar. Es una situación complicada, porque yo entiendo que Secretaría de Economía no puede dar dinero y decir “ahí si mejoras me avisas”. Sino que tiene que pedirle a las empresas los resultados, y estos deben darse en el mismo año en el que se dio el financiamiento, así que en la mayoría de los casos, el único resultado tangible que se puede dar es un certificado. ¿Cuál es tu opinión sobre MoProSoft? Creo que MoProSoft es un modelo muy bueno, y cumple una función muy necesaria, que es la de mejorar procesos en PyMEs desarrolladoras de software. Desgraciadamente, no ha tenido suficiente auge. No sé si sea por la situación de la industria, por falta de difusión, o qué. La actitud que yo encuentro en muchas empresas hacia MoProSoft es: “si lo que yo quiero es vender servicios a Estados Unidos, y www.softwareguru.com.mx

¿Cuál es la percepción en México de los consultores? En general a las organizaciones en México no les gustan los consultores, o creen que es algo muy sencillo de hacer. O sea, no le dan valor. Creo que es un problema cultural, pero también ha sido provocado por proveedores que dan un mal servicio, o que venden como consultoría algo que no lo es. Otro caso que se da es el de gente que tiene muchos conocimientos, pero no sabe dar consultoría. En fin, esos son retos que hay que enfrentar al vender consultoría.

Tenemos entendido que estás próxima a ser reconocida por el SEI como SCAMPI Lead Assessor, y que hay otros mexicanos en el mismo camino. ¿Qué significa esto para México? Va a ayudar a reducir los costos de las evaluaciones, ya que va a haber mayor disponibilidad de personas que puedan hacer evaluaciones CMMI, y no se va a gastar tanto en viáticos. Adicionalmente, los evaluadores mexicanos estamos más familiarizados con el contexto de las organizaciones de aquí. Por ejemplo, en Estados Unidos, una organización con menos de 500 personas es considerada como pequeña, y sabemos que eso es algo muy distinto para nuestro país. ¿Crees que estudiar Sistemas/Informática es una buena elección de carrera? Definitivamente. Te da una estructura mental y lógica fundamental. Tienes un campo enorme de trabajo, porque en todos lados se necesita software. Además, no sólo está la parte de programación, sino que hay una gran variedad de roles y especialidades, dependiendo de qué es lo que te gusta hacer. Por ejemplo, el área de testing es enorme. Al desarrollar software se aprende mucho de cómo funcionan las empresas y sus procesos de negocio, porque a fin de cuentas lo que se hace es crear sistemas que automaticen procesos. ¿Qué mensaje dejas a nuestros lectores? Les pido que estén conscientes de que estamos en una industria súper interesante, que es muy global y muy diversa, así que disfrútenla. Por otro lado, que trabajen con calidad, y que siempre busquen mejorar. Mejorar empieza desde uno como persona, y debe ser porque uno está convencido, no porque lo obligan. MAR-ABR 2007

Cualquier profesión requiere de herramientas; y el desarrollo de software no es la excepción. A través de las próximas páginas, pretendemos brindar un panorama respecto a los diferentes tipos de herramientas que se utilizan para desarrollar software. Así como sus propósitos, funcionalidad, la forma en que se integran, y cúales son las tendencias. Antes de proseguir, queremos enfatizar un par de puntos: el primero, es que debemos tener presente que el propósito de las herramientas de software es facilitar o agilizar actividades de la ingeniería de software. Por lo tanto, es fundamental, antes que nada, entender la práctica, y posteriormente, entender cómo es que una herramienta puede facilitarla. De otra forma, sólo somos prisioneros de las herramientas. El segundo punto, es que los siguientes artículos no buscan proveer una lista completa de productos y proveedores, simplemente buscan ilustrar el tipo de cosas que se puede hacer con las herramientas modernas. Dejamos en ustedes, la tarea de investigar más sobre alguna categoría de herramientas que les pueda interesar, conocer quiénes son los proveedores, y cuál brinda la solución más adecuada a las necesidades de su organización. Dicho lo anterior, comencemos ...

MAR-ABR 2007

www.softwareguru.com.mx

Open Source al Rescate Por Francisco Castrillo

l objetivo principal de este artículo es presentar un panorama sobre las herramientas de software libre u open source, relacionadas con la generación de un ambiente de desarrollo integral, que cubra las diferentes etapas involucradas en la creación de software.

•Diseño y arquitectura. •Desarrollo y pruebas unitarias. •Estabilización y pruebas de estrés. •En vivo (ya en producción). •Carga real, uso real, ambiente real ... •Detección de errores, cambios, mejoras ...

Aunque la mayor parte de las herramientas mencionadas son ampliamente utilizadas hoy en día, otras no cuentan con el mismo nivel de difusión y adopción. Sin embargo, la intención es destacar el impacto que tienen todas ellas en relación con el desarrollo colaborativo. Vale la pena resaltar que, estas herramientas no sólo son exclusivas para el desarrollo de proyectos open source, sino que se pueden utilizar para cualquier tipo de proyecto.

¿Cómo seleccionar las mejores herramientas para cada una de estas etapas? Las revisiones de producto son útiles, pero no son la última palabra, porque cada situación es única (como los proyectos), y los procesos de adopción en cada organización son muy variados. Algunos de los aspectos a considerar dentro de esta gama son: metodología y procesos; presupuesto para hardware-software, infraestructura actual; tamaño de proyectos y equipos de trabajo.

Un vistazo a las diferentes necesidades

A pesar de estas limitantes para la selección de herramientas, lo que está claro, es que debemos seleccionar aquéllas que nos ayuden a producir, conservar y administrar todo el material generado en los proyectos, así como los que promuevan la estandarización en el uso de las mismas.

Desde un punto de vista muy simplista y, sin estar apegado a alguna metodología específica, podemos identificar las siguientes etapas en el ciclo de vida de un proyecto: •Planeación y costeo.

www.softwareguru.com.mx

MAR-ABR 2007

Herramientas de colaboración Comencemos por mencionar algunas herramientas orientadas a coordinar y facilitar la colaboración entre los miembros de un equipo de trabajo. Aquí tenemos las siguientes categorías: Control de versiones El control de versiones es uno de los pilares de un buen desarrollo de software. Usado de forma adecuada, proporciona una bitácora de todos los cambios realizados a la documentación y al código fuente, siendo así una gran ayuda para la corrección de bugs. Una recomendación adicional es que todos los artefactos de los proyectos (código fuente, contenido estático, scripts para builds, documentación de análisis y diseño, material de cursos, acuerdos con el cliente, etcétera) sea administrado con una herramienta de control de versiones. Hoy en día existen dos grandes tecnologías para el control de versiones: CVS y Subversion; la primera de ellas es prácticamente de adopción universal; la segunda, cuenta con algunas mejoras de implementación que la colocan como el sucesor natural de CVS. Entre las características comunes están: •Repositorio central accesible vía Internet. •Resolución de conflictos vía “merging”, en lugar del concepto de “locking”. •Gran diversidad de clientes multiplataforma para acceder a los repositorios. Entre las principales diferencias a nivel conceptual (no de implementación), está el reemplazo de etiquetas (tags) y ramas (branches) de CVS por simple copiado y renombrado de archivos y directorios en Subversion. Issue tracking Utilizado para manejar las listas de pendientes a resolver y las solicitudes de mejora. Es indispensable contar con visibilidad de los asuntos por resolver, así como un mecanismo automatizado de asignación de tareas y notificación de alertas. Toda esta funcionalidad la provee una herramienta como Bugzilla, la cual fue originalmente desarrollada para atender las necesidades del proyecto Mozilla, y ahora se ha convertido en la herramienta por excelencia para manejo de issues. Los usos que se le pueden dar a la herramienta son muy variados: los desarro-

MAR-ABR 2007

lladores pueden rastrear defectos o bugs; los usuarios solicitan soporte, asignación de tareas de codificación y/o corrección, control de actualizaciones o parches y discusión sobre posibles mejoras. Discusiones técnicas En este rubro se pueden utilizar una diversidad de mecanismos que promuevan el entendimiento técnico del proyecto, así como la facilidad de dejar evidencia escrita del por qué se tomaron ciertas decisiones a lo largo del proyecto. Dentro de estas posibilidades nos encontramos los sitios web por proyecto, los foros de discusión, las listas de correo, HowTo’s y FAQ’s. En lo personal, me gusta la utilización de una lista de correo por proyecto, ya que es tan accesible y cotidiano como el correo electrónico, con la gran ventaja de dejar un histórico de las discusiones en web. Una de las opciones más utilizadas para generar estas listas de correo es MailMan, que ofrece una interfaz web para utilizar listas de correo electrónico, diversas opciones de entrega y suscripción a las listas. Otra alternativa de más reciente aparición son los grupos de Google, que además de proporcionar la funcionalidad de listas de correo, permite adjuntar archivos y crear páginas (tipo Wiki) desde la misma interfaz web.

Herramientas de desarrollo En cuanto a las herramientas de desarrollo se refiere, existen una infinidad de posibilidades para categorizarlas. Sin embargo, me enfocaré en esta ocasión, a las más apegadas a las etapas de construcción o implementación. Editores de texto Si consideramos que las herramientas son una extensión de nuestras manos, esto aplica mejor que en ningún otro caso para los editores de texto. Lo ideal es conocer un editor lo mejor posible y utilizarlo para cualquier tarea de edición: código, documentación, scripts, notas, entre otras. Las características esenciales que debe tener un editor son: •Configurable. Todo debe poderse adaptar a las preferencias del usuario (fonts, colores,

asociación de shortcuts, etcétera). •Extensible. Un editor no debe pasar de moda si surge un nuevo lenguaje o formato de texto. •Programable. Ya sea mediante la utilización de macros u otra funcionalidad equivalente, se deben poder realizar tareas complejas. Entre los editores open source más populares encontramos a Emacs, Xemacs y Judit, por mencionar algunos. A pesar de la sencilla interfaz gráfica que presenta, Emacs es uno de los editores más potentes que he conocido. Algunas de sus características son: •Ampliamente configurable y programable a través de Lisp. •Ligero: no se requiere mucho espacio de memoria para su instalación y ejecución. •Utiliza atajos o shortcuts. A pesar de que es un poco difícil aprenderse los atajos, una vez que se tienen dominados son extremadamente útiles. •Funcionalidad robusta y de gran diversidad: búsquedas, ejecución de comandos, ftp, soporte para múltiples buffers, highlighting, indentación automática; soporta diversos modos de edición, juegos, calendario, control de versiones, mail, etcétera. Automatización de tareas de compilación y despliegue (build systems) El estándar de facto para los proyectos en Java, es Ant. Para quienes están familiarizados con Unix, Ant es el equivalente al comando “make”, con la diferencia de que Ant utiliza archivos XML en lugar de makefiles. En cada archivo XML se describen los pasos y dependencias para ejecutar cada tipo de tarea: compilación, empaquetado, despliegue en servidores, etcétera. Las tareas se invocan a través de línea de comandos, o directamente desde un IDE. Ant es muy fácil de extender e incorporar tareas diversas como envío de correos electrónicos, verificación de estándares de codificación (CheckStyle), integración de control de versiones, pruebas unitarias (JUnit), automatizar la ejecución de tareas en servidores, etcétera. Con el uso extensivo que se ha hecho de Ant, surgió Maven, cuyo uso es menos generali-

www.softwareguru.com.mx

zado. Maven agrupa las “mejores prácticas” y asume cierta estructura de directorios con el fin de estandarizar tareas. Adicionalmente, provee una estructura que permite declarar las dependencias complejas entre librerías de diferentes proyectos. En lo personal, me gusta más la flexibilidad que provee Ant, ya que cuento con una infraestructura de muchas plantillas de proyectos diversos que me dan un buen punto de partida para cualquier nuevo proyecto. Sin embargo, creo que Maven puede ser una buena opción para quienes no cuenten con dicha infraestructura, o bien, para aquellos casos en que las dependencias entre proyectos o componentes es bastante significativa. Entornos gráficos de desarrollo (IDE) Los IDE’s son herramientas visuales que integran muchas de las características antes mencionadas (control de versiones, build systems, edición), y otras más avanzadas (modelado UML, construcción de interfaces gráficas, debugging, instalación en servidores de aplicaciones, refactoring) que no cubrimos en este artículo. La tarea de elegir un IDE es verdaderamente difícil. Cada una de las opciones presenta ventajas y desventajas. Sin embargo, podemos tomar en cuenta algunas consideraciones al momento de hacer esta elección: •Naturaleza del proyecto a realizar. Es importante considerar las características del proyecto a desarrollar para así, poder delimitar las necesidades que se deben cubrir. Una vez que se tiene un panorama del proyecto y sus requerimientos, podemos buscar un apoyo en los IDEs para que faciliten algunas de las tareas más laboriosas. •Hardware disponible. Aunque a veces este punto se pasa por alto, no debemos olvidar que generalmente los ambientes de desarrollo requieren de una capacidad mínima para que funcionen de manera óptima. •Flexibilidad de la herramienta. Existen herramientas que hacen verdaderas maravillas

en la generación de cierto tipo de proyectos, pero que al momento de quererlas integrar con otro tipo de tecnologías o herramientas, empiezan a generar problemas. •Estabilidad. Algunos IDEs tienden a deteriorar su funcionalidad al momento de ser utilizados en proyectos grandes con muchos componentes. •Documentación. Es conveniente revisar si existe buena documentación y soporte sobre el funcionamiento del IDE. •Perfil del desarrollador. Algunas características de los IDEs pueden ser útiles para unos y un estorbo para otros. De nada sirve tener asistentes para tareas que podemos realizar de mejor manera utilizando otro tipo de herramientas, metodologías, etcétera. Hablando principalmente de desarrollos en Java, al día de hoy destacan dos opciones como alternativas open source: Eclipse y NetBeans. En cuanto a la filosofía que promueven con su arquitectura, ambos fueron implementados alrededor de un pequeño núcleo con todas sus características implementadas como plug-ins. Ambos sirven como plataforma base para otras herramientas de valor agregado que proveen las empresas que fundaron a estos proyectos. Por ejemplo: en el caso de NetBeans, éste sirve de base para el Java Studio Creator y Java Studio Enterprise, ambas herramientas de Sun Microsystems. La primera está dirigida a desarrolladores de Visual Basic que buscan hacer el salto a la plataforma Java; mientras que la segunda, está más dirigida a desarrollo de aplicaciones corporativas. De forma similar, en el caso de Eclipse, existen diversos productos de IBM construidos sobre esa plataforma, especialmente de las líneas de Rational y Websphere. Tal es el caso del WebSphere Studio Application Developer. A pesar de que la opción de utilizar un IDE puede ser muy tentadora, en algunas ocasiones es mejor utilizar sólo un buen editor

de texto. De cualquier forma, no olvidemos que las herramientas de programación deben ayudar a: •Minimizar costos de desarrollo. •Automatizar procesos. •Reducir errores. Para decidir si es conveniente o no utilizar una herramienta de desarrollo, debemos preguntarnos si ésta nos ayuda o no a cumplir con estos objetivo.

Conclusión Independientemente de la selección de herramientas para generar nuestro entorno de desarrollo colaborativo, conviene tener muy presente dos cosas: 1. Las herramientas de colaboración no son un sustituto de la comunicación directa con los otros miembros del equipo de trabajo, también es importante establecer las “reglas de uso” de las herramientas para facilitar su adopción 2. En cuanto a las herramientas de desarrollo, yo considero de mayor valor contar con un “esquema estándar” de proyecto, que funcione con cualquier herramienta de desarrollo, en lugar de “casarme” con alguna en particular.

Referencias •SourceForge - sourceforge.net •CVS - www.nongnu.org/cvs •Subversion - subversion.tigris.org •Bugzilla - www.bugzilla.org •Google Groups - groups.google.com •Emacs - www.gnu.org/software/emacs •Jakarta Ant - apache.ant.org •CheckStyle - checkstyle.sourceforge.net •JUnit - www.junit.org •Maven - maven.apache.org •MailMan - www.list.org •Netbeans - www.netbeans.org •Eclipse - www.eclipse.org

Francisco Castrillo es Director de Soluciones de Nexusware, empresa pionera en México en el desarrollo de soluciones corporativas basadas en Java. Como expositor, ha impartido seminarios relativos a la tecnología Java EE en diversos foros a nivel nacional e internacional. Francisco es miembro del Consejo de la Comunidad Java México (www.comunidadjava.org) y es egresado de Matemáticas Aplicadas del ITAM.

www.softwareguru.com.mx

MAR-ABR 2007

En un mundo en el que el software es cada vez más importante y requiere mayor calidad, el proceso de prueba es parte crucial del desarrollo de software. Sin embargo, sabemos que a este proceso, típicamente se le asignan pocos recursos y tiempo. Es así que la mayoría de los líderes de proyecto y testers requieren encontrar y aplicar técnicas que hagan más ágil y eficiente dicho proceso.

Pruebas ágiles

Mediante automatización efectiva Por Ariel Sucari

ste artículo expondrá los subprocesos de la disciplina de pruebas que más carga de trabajo les ocasiona a sus ejecutores, y mostrará cómo la técnica propuesta otorga velocidad a la ejecución de dichas actividades, logrando una notable disminución en el tiempo total del proceso. Basada en el concepto: “marco de ejecución de pruebas automatizadas”. Esta técnica logra que los proyectos que la implementan, obtengan la calidad deseada en el tiempo estimado.

están a unas horas del compromiso de liberar un sistema a producción?

Las dos áreas de mayor oportunidad

Luego de hacer varios intentos en la búsqueda de la eficiencia en la disciplina de pruebas, he llegado a la conclusión de que no se pueden obtener pruebas con una cobertura aceptable, sin hacer uso de una herramienta para la implementación de pruebas automatizadas. Y es que es humanamente imposible, rea-

¿Cuántas veces les ha ocurrido que sus diseñadores de prueba no terminan de diseñar y/ o detallar sus casos, cuando éstos ya deben empezar a ejecutarse? ¿Cuántas veces llevan el 40 ó 50% de la ejecución de las pruebas y

MAR-ABR 2007

Estos escenarios ejemplifican los dos subprocesos de pruebas, que más tiempo, implican en un proyecto de desarrollo de software: el diseño de los casos de prueba y la ejecución de éstos. Es por ello que cualquier solución que intente agilizar dicho proceso, debe enfocarse primeramente en agilizar la definición y ejecución de casos de prueba.

lizar todas las pruebas requeridas para que un sistema tenga una calidad aceptable, en los tiempos que se colocan como meta, los proyectos actuales. A medida que van creciendo las funcionalidades de un sistema, con el correr del tiempo y las iteraciones de desarrollo, la cantidad de casos de prueba a ser construidos y ejecutados, aumenta exponencialmente; esto se traduce irremediablemente en tiempos de pruebas mayores y metas de proyectos incumplidas. Por esto, considero que cualquier proyecto de software con cierta importancia, debe implementar pruebas automatizadas como soporte al proceso de pruebas, y para implementar esto recomiendo aplicar el concepto del marco de ejecución de pruebas.

www.softwareguru.com.mx

El marco de ejecución

Factores críticos de éxito

La solución que describo se implementa utilizando una herramienta de pruebas automatizadas que permita crear lo que se conoce como un “marco de ejecución de pruebas automatizadas”.

El error más común es, leer un artículo de estas características y lanzarse a comprar una herramienta de automatización de pruebas, y entregárselas al equipo esperando los resultados aquí descritos. El hacerlo, no sólo lleva a la frustración personal de cada uno de los involucrados en el proyecto, sino al escepticismo por parte de la organización, hacia la automatización de pruebas. Para resolverlo, deben tenerse en cuenta una serie de puntos:

Con esto me refiero a que la herramienta debe permitir leer de una fuente de datos externa que contenga los casos de negocio que diseñaron los analistas y sumarlo a los casos de pruebas que diseñen los ingenieros de pruebas, para luego volcarlos a la aplicación. El marco de pruebas automatizado debe ser capaz de analizar, si luego de introducir todos los datos leídos, el resultado que muestra el sistema es el esperado. Lo interesante de la metodología se basa en que, tanto la cantidad de campos que contenga la fuente de datos externa, como la cantidad de casos de pruebas a ejecutarse, pueden variar sin que esto afecte al proceso. Es decir, el marco de pruebas será capaz de volcar a la aplicación, los casos de pruebas, teniendo como entrada una fuente de datos de entrada dinámica. La figura 1 ilustra a grandes rasgos el funcionamiento de esta técnica.

La curva de la “JOTA”. Es muy frustrante comenzar un proyecto pensando en que pasaremos de A a C sin pasar por B. Toda innovación tiene un punto en el que el equipo o persona, baja la productividad debido al tiempo de aprendizaje. En los proyectos de automatización de pruebas, muchas organizaciones abandonan los esfuerzos de implementación cuando se encuentran en el punto B, por desconocimiento de la curva de aprendizaje. Es de suma importancia, antes de comenzar el proyecto, diseñar la curva y estipular los tiempos previstos para transitar desde A hacia C detallando expresamente el punto B.

Figura 2. La curva jota

Figura 1. Marco de pruebas automatizadas

Con esto se logran dos cosas muy importantes que contribuyen a mitigar los riesgos antes mencionados. 1. Los analistas del sistema generan una parte importante de los casos de prueba. 2. La ejecución de las pruebas ya no depende esencialmente de la intervención humana, ya que se puede automatizar.

Contar con personal con experiencia en desarrollo. Un factor crítico en la implementación de un marco de pruebas es, tener la participación en el equipo de trabajo de recursos humanos con habilidades de desarrollo, preferentemente en el lenguaje de programación de la herramienta de automatización. El no tomar al proyecto de automatización como un proyecto de desarrollo, es uno de los errores más graves que se comete al encarar una implementación de este estilo; debido a que una mala arquitec-

tura en el desarrollo del marco de pruebas, no permitirá el éxito del proyecto. Pensar que con la automatización se descartarán las pruebas manuales. Muchas organizaciones piensan que luego de la finalización de este proyecto, prescindirán de los probadores manuales, y entonces no prevén contrataciones para el área de pruebas. Existen tipos de pruebas en las cuales la automatización no es una técnica factible. (Ejemplo: ver si la barrera de una caseta se levanta al emitir el ticket). Incluso en aquellas pruebas que pueden automatizarse, es conveniente que en una etapa inicial del desarrollo, se efectúen manualmente.

Conclusión El marco de automatización de pruebas es un concepto que en el ámbito de la investigación se maneja desde hace varios años, pero me he dado cuenta que pocas organizaciones están familiarizadas con esta técnica. Me he preguntado el por qué de este hecho, y no he dado con una respuesta certera. Tal vez se deba a que las herramientas en la antigüedad no eran lo suficientemente flexibles como para que los programadores se sintieran cómodos, y se animaran a crear un marco como el que describo. Sin embargo, las herramientas en la actualidad son muy poderosas, incluso algunas de ellas ya permiten la introducción de código en lenguajes tan conocidos y potentes como Java y .Net. Creo que la verdadera razón, es que no se ha dado suficiente difusión a esta técnica. Espero que escribir un artículo en un medio de distribución masiva como este, pueda ayudar a generar conciencia en las organizaciones del valor real de esta práctica.

Ariel Sucari, es gerente de consultoría en Itera, cursa el MBA ejecutivo de la Universidad de las Américas Puebla, graduado de la Universidad CAECE en Buenos Aires, Argentina. Ha participado y coordinado proyectos de la disciplina de pruebas, en Inglaterra, Estados Unidos, Venezuela, Argentina y México, durante los últimos 8 años.

www.softwareguru.com.mx

MAR-ABR 2007

Integración de Herramientas Un Nuevo Paradigma para el Desarrollo Empresarial Por Marcos del Pozo

Como sabemos, el desarrollo de software empresarial involucra diversos aspectos, tales como la definición de actividades, utilización de metodologías, gestión de requerimientos, pruebas, etcétera. Integrar todos estos elementos de manera efectiva es una tarea que puede ser difícil, pero es indispensable, sobre todo porque lo hacemos en busca de un proceso más rentable y que genere software de calidad.

asta hace pocos años, un desarrollador de software que quisiera utilizar herramientas para todo el ciclo de vida, tenía que recurrir a muchas herramientas diferentes, que se ejecutaban de forma independiente, y no se comunicaban entre sí. Esto nos llevaba al escenario de que, al mismo tiempo era necesario tener cuatro o cinco aplicaciones abiertas (un IDE, un controlador de versiones, el repositorio de requerimientos y una consola para depurar, entre otros) al estar desarrollando. Como ustedes saben, esto tiene dos grandes inconvenientes: el primero es que se requiere estar cambiando de ventana en ventana, lo cual no es muy productivo; y el segundo, es que cada aplicación abierta se lleva una buena cantidad de recursos de la computadora. Afortunadamente, en los últimos años los proveedores de herramientas han mejorado muchísimo las capacidades de integración entre herramientas. La novedad aquí no es que

MAR-ABR 2007

dos herramientas diferentes se puedan comunicar, sino que dentro de una herramienta se pueda “embeber” a otras, a través de plug-ins y perspectivas. Así, el desarrollador sólo requiere abrir su IDE, y desde ahí tiene toda la funcionalidad que requiere. Aunque este paradigma ya existía desde hace tiempo, tal vez la herramienta que realmente lo hizo despegar fue Eclipse, que fue pensada no como un IDE, sino como una plataforma para herramientas de software. Microsoft aprendió de esto, y de hecho, la versión 2005 de Visual Studio tiene una filosofía similar. La tendencia es que los proveedores de herramientas de software están dejando de ofrecer ediciones independientes de sus productos, y en su lugar, los ofrecen como plug-ins para Visual Studio y/o Eclipse.

Una plataforma para la colaboración Para ilustrar este nuevo paradigma, voy a

tomar como referencia a Visual Studio Team System, y haré un ejercicio de cómo se integra con diferentes herramientas para resolver actividades de todo el ciclo de software. Como posiblemente sabrán, Visual Studio Team System (VSTS) es la propuesta de Microsoft para el ciclo de vida de desarrollo de software empresarial. Team System se distingue del Visual Studio normal (o “a secas”), en cuanto a que ofrece un conjunto de herramientas y tecnologías para el ciclo completo de desarrollo de software empresarial, donde se requiere tener un seguimiento estricto a los proyectos y sus requerimientos, así como un control de versiones robusto. El motor de Visual Studio Team System es un componente denominado Team Foundation Server. Éste es el que provee capacidades como la colaboración entre miembros del www.softwareguru.com.mx

equipo, control de versiones, gestión de cambios, administración de la configuración, y elaboración de informes.

los, o ingeniería en reversa para que a partir de programas, se actualicen los modelos.

Gestión de requerimientos

La empresa AutomatedQA, cuenta con una herramienta llamada TestComplete, que tiene una completa integración con la edición Tester de VSTS. TestComplete ofrece un ambiente de pruebas sistemático, automatizado, y estructurado para desarrollos en lenguajes como .NET, Java, Visual C++, Visual Basic, WPF (XAML), Delphi, C++Builder y aplicaciones web. Además con TestComplete se pueden probar aplicaciones de PowerBuilder, FoxPro y Access.

Para consolidar el proceso, y tener una herramienta sólida para la definición de requerimientos que se complemente fácilmente, podemos integrar una herramienta de Borland que se llama CaliberRM para Visual Studio Team System. Este es un sistema de gestión de requisitos empresariales, diseñado para ayudar a los analistas a facilitar la colaboración y comunicación entre negocio, analistas, desarrolladores, probadores, arquitectos y otros interesados. CaliberRM provee la funcionalidad requerida por el rol de “analista de requerimientos”, ofreciendo así a los equipos de desarrollo, la capacidad de reunir, seguir y administrar los requerimientos directamente desde VSTS. Esta herramienta de Borland, además de ser una gran alternativa para la gestión de requerimientos, es de gran ayuda cuando se desarrollan proyectos basados en el MSF (Microsoft Solutions Framework). De la misma empresa, también podemos integrar Caliber DefineIT, una herramienta que nos ayuda en el aseguramiento de los requerimientos del software, para que sean definidos completa y acertadamente desde el principio al ofrecer a los analistas y usuarios, la capacidad de colaborar para capturar los detalles de escenarios posibles y validarlos a través de la creación de guiones visuales. Es así como, con la integración de las herramientas de Borland, podemos asegurar la entrega del software alineada a la demanda de los usuarios y cumplir con los requerimientos del negocio.

Diseño y arquitectura Enterprise Architect es una excelente herramienta de Sparx Systems para modelar sistemas con UML 2.1. El componente MDG Integration for Visual Studio, nos permite acceder desde Visual Studio los modelos de Enterprise Architect. Es así que se puede hacer generación de código a partir de mode-

Gestión de pruebas

Soporte a entornos heterogéneos Hemos comentado sobre la colaboración de propuestas que impactan en el ciclo de vida del desarrollo. Sin embargo, nos debemos preguntar: ¿qué pasa cuando tenemos una infraestructura heterogénea? Como sabemos, los equipos de desarrollo no sólo trabajan en ambientes Windows, sino también lo hacen con sistemas operativos como Linux, Solaris o Mac OS X. Es aquí donde entra una propuesta de SourceGear llamada: Teamprise, que es una excelente opción para resolver dicha problemática. Esta herramienta extiende las características de Team Foundation Server a entornos heterogéneos. Con Teamprise, los administradores, desarrolladores y probadores trabajando con distintos sistemas operativos, pueden acceder a TFS. Por ejemplo: un desarrollador de Java trabajando desde Eclipse en Linux, podría utilizar TFS para toda la colaboración y seguimiento al proyecto. Esto permite que las organizaciones integren herramientas sin necesidad de modificar su infraestructura.

Acceso universal Por último, quiero hacer mención a una herramienta Teamplain, de la empresa DevBiz Business Solutions. Esta es una herramienta que a través del web nos permite administrar los elementos de trabajo de Team Foundation Server, sin necesidad de tener

instalada alguna versión de Visual Studio Team System, o Team Explorer. Teamplain se convierte en una interesante opción para aquellos usuarios no tan involucrados con el proceso de desarrollo, sino más bien, con un perfil administrativo, por tratarse de una herramienta sencilla de utilizar.

Conclusión La experiencia nos confirma que, el desarrollo de software es un proceso difícil. Entregar un producto de calidad y que cumpla con las expectativas del cliente, es aún más complicado. Sin embargo, adoptar herramientas que faciliten este proceso nos ayudará a acercarnos de una mejor manera a cumplir con este objetivo. La colaboración e integración de las herramientas impactará indudablemente en la mejora del desempeño de cada uno de los roles participantes del desarrollo. Y lo más importante, es que no tenemos que cambiar para adoptar cada una de estas herramientas, sino al contrario, podemos integrarlas de acuerdo a nuestras necesidades en busca de la consolidación del proceso de desarrollo de software, que poco a poco se vaya acercando a cumplir con la generación de un software de calidad y un cliente satisfecho.

Referencias a las herramientas mencionadas • www.microsoft.com/spanish/msdn/ vs2005/editions/team/default.mspx • www.borland.com/us/products/caliber • www.sparxsystems.com/products/ mdg_integrate.html • www.automatedqa.com/products/ testcomplete • www.teamprise.com • www.devbiz.com/teamplain/webaccess

Marcos del Pozo Gómez actualmente colabora como Instructor Senior en la empresa Intersoftware. Cuenta con las certificaciones MCP, MCAD, y MCSD; y su especialidad es el desarrollo de código seguro y herramientas de desarrollo empresarial. Marcos es Ingeniero en Sistemas Computacionales, egresado de la Universidad Tecnológica de México. Su principal entusiasmo es poder sembrar semillas que impulsen el desarrollo de la tecnología en nuestro país.

www.softwareguru.com.mx

MAR-ABR 2007

La evolución de las tecnologías de la información nos ha llevado al punto en que, logramos comunicarnos eficientemente y en tiempo real con compañeros de trabajo que se encuentran geográficamente distribuidos. Hoy en día, es de lo más normal trabajar por medio de oficinas virtuales, comunicarnos a través de mensajería instantánea, video conferencia, voz por IP, y la lista continúa. ¿Cómo es posible que nos podamos relacionar, comunicar, intercambiar formas de pensar?, y mejor aún, generar valor a través de la información que producimos en nuestros equipos de trabajo...

Una Nueva Forma de Comunicación Usando Web 2.0 como una Herramienta Empresarial Por Luis du Solier

sta evolución nos guía hacia una nueva forma de comunicación, conocida como Web 2.0, la cual podríamos decir, se enfoca en tres ideas principales: 1. Internet no sólo vista como fuente de información, sino también como un repositorio universal para la generación de contenido. Es decir, no sólo ver a la red de redes como un lugar para “navegar”, sino para encontrar información y, a partir de ésta, generar mayor conocimiento. El concepto de comunicación entre los usuarios de la Internet está cambiando, esto es en esencia diferente de simplemente publicar información de interés, o incluso un catálogo de ventas, o encontrar trabajo. Los Blogs y los Wikis, soportan la posibilidad de la distribución y retroalimentación de distintas ideas, pensamientos, e incluso innovación. Esta forma de relacionarse, será llevada a ambientes mucho mayores, empezando por las universidades, donde los estudiantes aprenden a relacionarse con sus compañeros y profesores; a compartir ideas, estrategias, formas de pensar y actuar, a niveles incluso profesionales y de negocios. Las herramientas y soluciones de productividad que proveen productos como Web Office, seguirán este mismo camino: el que la Web no sólo es para consumirse de forma unidireccional, sino que aporte un apoyo para la creación de una comunidad universal de conocimiento. Los profesionistas podrán usar los Blogs y Wikis como un medio disponible para hacer más eficiente la comunicación en las empresas, incluso para compañías transnacionales donde no es tan fácil mantener el contacto y comunicación, o estar enterado de lo que se está haciendo al otro lado del mundo. Inclu-

MAR-ABR 2007

sive podrán utilizar estas herramientas como medios para coordinar esfuerzos, habilidades, investigación y desarrollo, seguimiento de cuentas, coordinación de proyectos e incluso la capacidad de poder contar con espacios de discusión instantáneos sin que la localidad geográfica parezca un impedimento. 2. La publicación de contenido, para ser consumida y utilizada a través de muchos medios, representa una ventaja significativa en la comunicación de información. Con el uso de Blogs y Wikis a nivel empresarial, cuando una persona escribe o publica un artículo, la información se almacena con un formato estructurado. Al ser publicado de esta forma, quiere decir que se guarda con un formato universal que puede ser entendible o leído por cualquier tipo de lector en formato XML. Como sabemos, XML es un estándar de descripción de datos que se emplea en todo el mundo, con la finalidad de contar con un idioma universal para compartir información sin importar el sistema, solución, plataforma o infraestructura donde se encuentran sustentados los sistemas que llevarán acabo esa transferencia o intercambio de información. XML define el contenido mismo que incluye, es decir, explica o detalla la información que viaja en un mensaje. De esta forma, cualquier sistema receptor podrá entender la información que una aplicación emisora envía, independientemente de la plataforma, infraestructura y código fuente en el que se haya desarrollado la solución. No es necesario explicar el valor de este estándar, pues sólo con pensar en modos de comunicación o envío de información entre departamentos o áreas de trabajo es suficiente. También es posible pensar en el lenguaje XML como formato para la comunicación entre empresas, proveedores, clientes, etcétera; para esto sería necesario establecer las nor-

mas que regulen dicha comunicación para que sea confiable, y segura. Ahora, muchos lectores dedicados a analizar la información publicada en Blogs o Wikis, lo hacen a través de mecanismos que se les llama Canales o Feeds, que están dedicados a consumir la información que se publica por ejemplo en un Blog, acerca de un tema o categoría en particular. Cada vez más, hay portales corporativos, por ejemplo: de noticias o periódicos, incluso páginas web, que permiten la suscripción a dichos canales de publicación de contenido a través de lo que se le llama RSS. Uno puede darse cuenta cuando está disponible al público, porque se localiza un icono generalmente con la leyenda “RSS” (también existen otros como “atom” y “opml”). Esta siglas significan Really Simple Sindycation, y es la forma en la cual es interpretado y publicado el contenido del sitio o página al público en general (en formato XML) para que un usuario pueda subscribirse al canal de información y recibir actualizaciones en tiempo real directamente en su computadora a través del lector de RSS de su elección (existen otros tipos de lectores de RSS que pueden configurarse para recibir las actualizaciones de información vía correo electrónico, consultando una página web, etcétera). Llegará un punto en que la información podrá ser usada de varias formas eficientemente. Por ejemplo: la información publicada por un empleado acerca del seguimiento de sus proyectos, gracias al potencial de los Blogs y Wikis, podría ser consumida de igual forma por Recursos Humanos para así, contar con un reporte automático del desempeño del personal de acuerdo con sus responsabilidades; y por otra parte, podría existir también www.softwareguru.com.mx

el mecanismo que agrupase toda la información de seguimiento que tuviera que ver con “X” cliente o proyecto, independientemente del empleado que le de seguimiento o lo publique. Esto ya es posible.

Escenario en un proyecto de software

3. Hágalo usted mismo. La posibilidad de ser autosuficiente en tareas sencillas sin depender del departamento de soporte de TI de la empresa, genera un gran valor al usuario final. Hoy en día, existe la necesidad de poder interactuar con la información a través de distintas aplicaciones, para así tener la opción de presentarla a varias personas con distintos privilegios e intereses. Hay escenarios donde incluso se genera el reporte por un lado, y por medio del conocido y muy utilizado copy-paste, se proporciona la información a otros sistemas.

Hablemos del potencial de los Blogs en un proyecto de desarrollo de software. Imaginemos que, el personal de la organización cuenta con su propio Blog, que contiene información relacionada a cada uno de ellos. Por ejemplo: sus habilidades o competencias, los proyectos en los que ha trabajado y en lo que se encuentra actualmente. Podríamos renombrar estos Blogs como “Página Personal del Profesionista”. Esto podría ser la base de una estructura que sustentara y permitiera relacionar automáticamente a personas, de acuerdo a sus capacidades y habilidades; y éstos, relacionados a los proyectos que han desarrollado o les han dado seguimiento de acuerdo a la cartera de clientes que lleva la empresa.

La tendencia va hacia la construcción y elaboración de soluciones inteligentes que permitan a los usuarios finales la posibilidad de generar sus entornos de trabajo de manera sencilla y de la mano, de modo tal que, les permite llevar a cabo sus actividades diarias de modo eficiente y sin necesidad de depender del área de TI, por lo menos para las tareas más comunes.

¿A dónde voy con esto? Pensemos en definir por lo pronto tres tipos de Blogs: Personales, Clientes y Proyectos. Los Blogs tipo Cliente y Proyecto, serían editados o actualizados por un grupo de personas, que son los que llevan la cuenta del cliente o el proyecto correspondiente. Ahora, al momento que una persona registrara como terminada una actividad correspondiente a un

proyecto, se podrían actualizar los tres Blogs: en el personal se actualizaría la información relevante al desempeño del individuo; en el del proyecto se actualizaría la información relevante al avance del proyecto, y en el del cliente se publicaría la información relativa al impacto que tendrá hacia el cliente la conclusión de dicha tarea. Esto ya se puede hacer hoy en día, pues existen herramientas y procedimientos que permiten actualizar información automáticamente que se publique en un Blog, y que se replique en otro. ¿Y, qué logramos con esto? Bueno, cuando una persona registre un nuevo proyecto, automáticamente se actualizaría la lista de proyectos en el Blog correspondiente, de igual forma la lista de responsabilidades actuales en el Blog personal, y en otro Blog definido, la lista de proyectos de un cliente, que se estén ejecutando. Con esta sencilla estructura, el personal de la organización podría encontrar la información automáticamente estructurada de manera muy sencilla y rápida. Ahora, muy posiblemente esta estructura evolucionará hacia algo más complejo, pero estas son las bases.

Luis Du Solier Grinda es consultor especialista en herramientas de colaboración enfocadas a la productividad empresarial y personal. Es reconocido MVP por Microsoft en herramientas de colaboración, y es líder de la comunidad de IT Pros de Microsoft TechNet México acerca de herramientas de productividad. También es vocero de la alianza Culminis para apoyo a comunidades de tecnología en México. Luis puede ser contactado a través de su blog en http://lduso.spaces.live.com o en luis.dusolier@gmail.com

www.softwareguru.com.mx

MAR-ABR 2007

Administración de Cambios del Software Principios y Herramientas

Por Ysalia Bautista y Rigoberto Calleja

Cuando estamos desarrollando y dando mantenimiento a un producto de software, los cambios son inevitables, de hecho, son lo único que se mantiene constante dentro de un proyecto de desarrollo; ya sea porque el cliente necesita que se efectúen cambios, porque se cometieron errores, o simplemente porque el entorno en el que se desenvuelve el producto, evoluciona.

a incorporación de esos cambios al software de forma descontrolada, frecuentemente provoca caos en los proyectos, retrasos en la entrega de los productos y problemas de calidad. Por ejemplo: sin una adecuada administración de cambios, nuestros compañeros de equipo pueden cambiar parte del diseño del aplicativo, olvidándose de comentarnos. Como resultado, nosotros escribiremos código que es incompatible con los cambios al diseño, lo cual, eventualmente requerirá que nosotros, o nuestros compañeros de equipo tengan que rehacer parte del trabajo.

Proceso de solicitud de cambios Cualquier organización que desee administrar adecuadamente los cambios al software, se debe asegurar de que los cambios que se propongan se evalúen cuidadosamente, que las personas indicadas tomen decisiones sobre esos cambios, que los cambios se comuniquen oportunamente a todos los afectados, y que el proyecto incorpore los cambios de una forma disciplinada. Para conseguir esto es necesario contar con un proceso de solicitud de cambios. El proceso de solicitud de cambios provee procedimientos formales para: registrar so-

licitudes de cambio; analizar la información del por qué es requerido el cambio, y el impacto que tendrá; y autorizar, rechazar o modificar la solicitud de cambio. Las solicitudes de cambio pueden provenir de cualquier usuario o interesado, en cualquier punto del ciclo del software, e incluir una solución propuesta, prioridad e impacto, el cual debe ser analizado, aprobado y rastreado formalmente. Una solicitud de cambio puede originarse, por ejemplo, a partir de un defecto en el producto de software, de una petición de mejora o de un cambio a un requerimiento.

Ysalia Bautista (ybautista@itera.com.mx) es Process Consultant de Itera especializada en la disciplina de Administración de Cambios. es IBM® Certified Administrator for Rational ClearQuest, y cuenta con mas de diez años de experiencia brindando servicios de consultoría en la implantación de herramientas de gestión del ciclo de vida de desarrollo de software. Rigoberto Calleja Cervantes (rcalleja@itera.com.mx) es Process Consultant de Itera especializado en la plataforma .NET®. Tiene amplia experiencia en el desarrollo de software y en la implantación de herramientas de gestión del ciclo de vida de desarrollo. Actualmente está cursando el Certificate in Software Engineering en la Universidad Carnegie Mellon.

MAR-ABR 2007

www.softwareguru.com.mx

El proceso de solicitud de cambios nos permite dar seguimiento a las solicitudes de cambio y efectuar mediciones acerca de la actividad del cambio. Una vez que una solicitud es recibida, una evaluación técnica (análisis de impacto) se lleva a cabo para determinar qué modificaciones se requerirían y si la solicitud de cambio debe ser aprobada. Tener un buen entendimiento de las relaciones entre los elementos de software es importante para llevar acabo el análisis de impacto. Finalmente, una autoridad establecida evaluará todos los aspectos del cambio propuesto y, aprobará, modificará, rechazará o pospondrá dicho cambio. La autoridad para aprobar o rechazar los cambios generalmente se le conoce como comité de control de cambios.

Herramientas para automatizar la administración de cambios El uso de herramientas puede ayudar a que el proceso de solicitud de cambios se ejecute de manera más eficiente; la automatización nos puede apoyar para iniciar solicitudes de cambio, hacer cumplir el flujo del proceso de cambios, capturar las decisiones del comité de control de cambios y obtener reportes acerca de la información del proceso. Sin embargo, no hay que olvidar que una herramienta no es un proceso. Emplear una herramienta para administrar los cambios de software nunca reemplazará a un proceso bien definido, que describa el contenido y la forma de procesar las solicitudes de cambio. Para brindar un panorama más real sobre el tipo de funcionalidad que proveen las herramientas de administración de cambio, hemos escogido dos herramientas para estudiarlas: IBM Rational ClearQuest, y Microsoft Team Foundation Server. En las siguientes páginas presentamos nuestros comentarios al respecto.

IBM Rational ClearQuest Es una herramienta con la que podemos crear, actualizar, administrar y dar seguimiento a solicitudes de cambio de acuerdo a las necesidades de nuestra organización. En ClearQuest, toda solicitud de cambio debe tener un ciclo de vida definido, que describe el flujo posible de acciones y estados que puede seguir una solicitud. El diagrama de estados en la figura 1, muestra un ejemplo de ciclo de vida para una solicitud de cambio. ClearQuest puede manejar diferentes tipos de solicitud de cambio, cada una con un ciclo de vida diferente. Por ejemwww.softwareguru.com.mx

Figura 1. Ejemplo de ciclo de vida para una solicitud

plo: una solicitud para un nuevo requerimiento debería manejarse de forma diferente que un registro de defectos. Es posible modificar los tipos de solicitud default y ajustarlos a las necesidades específicas de cada organización.

Para visualizar y administrar las solicitudes de cambio, ClearQuest soporta diferentes tipos de cliente (Windows, Linux/Unix, Web). Al igual que con los ciclos de vida, cada tipo de solicitud puede tener interfaces de usuario diferentes. Por ejemplo: para generar un nuevo requerimiento, se requiere introducir información diferente que para registrar un nuevo defecto.

ción sobre el progreso del proyecto a través de las consultas, gráficas y reportes. Estas métricas pueden ser de tres tipos: •Distribución. Analiza el estado actual de un grupo de registros, por ejemplo: número de solicitudes asignadas y resueltas por desarrollador. •Tendencia. Comportamiento de los registros durante un período de tiempo en específico, por ejemplo: áreas con mayor cantidad de solicitudes registradas durante en un trimestre. •Tiempo. Indican cuánto tiempo ha permanecido un registro en un determinado estado, por ejemplo: número de solicitudes que han permanecido en el estado de registrada por más de un mes.

Figura 2. El cliente web permite gestionar una

Figura 3. ClearQuest provee una gran variedad

solicitud de cambio

de reportes

En caso de que estemos en presencia de un escenario con equipos de trabajo distribuidos geográficamente, entonces es conveniente usar ClearQuest MultiSite, que permite la comunicación entre distintos repositorios a través de un esquema de replicamiento.

Pros •La versatilidad de ClearQuest permite utilizarla no sólo para administrar cambios, sino para resolver otro tipo de workflows. •Tanto el cliente como el servidor de ClearQuest, están disponibles en diversos sabores de Windows, Unix y Linux. El repositorio de datos puede montarse en DB2, Oracle, SQL Server, SQL Anywhere, e incluso Access. •La funcionalidad de auditorias nos permite saber qué campos de la forma se cambiaron, quién los cambió, cuándo y, en qué acción y estado.

Interfaz de usuario

Reportes y métricas Una solicitud de cambio de ClearQuest cuenta con una variedad de atributos: estado, tipo de cambio, severidad, prioridad, área afectada etcétera; que se almacena en un repositorio del que se puede extraer informa-

MAR-ABR 2007

•ClearQuest cuenta con funciones avanzadas de seguridad como soporte a firma electrónica para autenticación, y acceso a LDAP a través de SSL. Contras •La creación de reportes personalizados puede consumir tiempo, o parecer compleja si no se está familiarizado con SoDA o Crystal Reports. ClearQuest es una solución muy poderosa y flexible. Sus capacidades pueden satisfacer las necesidades de incuso, las organizaciones más exigentes y complejas.

Microsoft Team Foundation Server (TFS)

trabajo predefinidos, como por ejemplo: las solicitudes de cambio y los defectos. Team Foundation permite personalizar los campos de los elementos de trabajo y la forma cómo se presentan en la pantalla; así como el flujo de trabajo asociado a ellos.

Control de cambios en código TFS también administra los cambios al código fuente, de forma tal que, en cualquier momento se pueda saber quién y qué modificó el código; y qué solicitudes de cambio, requerimientos y/o defectos están asociados a dicho cambio. Gracias a este control de código, es posible obtener una versión específica del proyecto, hacer ramificaciones (branch) o unir ramas (merge).

Es una plataforma de colaboración, que permite administrar y dar seguimiento al avance y al estado del trabajo de los proyectos de software, en base a una serie de servicios Web y repositorios integrados. Por ello, su funcionalidad no se limita a la administración de cambios, sino que también incluye otras funciones como control de código, portales de proyecto, generación de builds, y guías para metodologías de desarrollo y modelos de mejora de procesos.

Team Explorer Team Explorer es el cliente default para interactuar con TFS. Este es un componente que se ejecuta dentro de Visual Studio, aunque a través de herramientas de terceros también se puede ejecutar dentro de otros IDEs, como por ejemplo Eclipse. Team Explorer permite ver los diversos activos del proyecto (código fuente, modelos, reportes, etcétera). Fig. 4 El Team Explorer como perspectiva dentro de Eclipse

Figura 5. El Source Control Explorer permite la administración de cambio de código

Reportes Team Foundation incluye un almacén de datos en el que se recopilan los datos operativos que provienen de los elementos de trabajo. Este almacén es empleado por los SQL Reporting Services para producir los reportes que correlacionan la información de elementos de trabajo, control de código fuente, resultados de pruebas, análisis de código y/o generaciones de producto.

Elementos de trabajo TFS emplea el concepto de elemento de trabajo para dar seguimiento a la asignación y al estado del trabajo asociado al ciclo de desarrollo. Existen varios tipos de elementos de

MAR-ABR 2007

Orientación del proceso, plantillas de proceso y proyectos de equipo Visual Studio Team System como familia de productos, tiene un enfoque hacia proceso. Provee guías acerca de roles, actividades, productos de trabajo y reportes personalizados, y mediante plantillas de proceso se puede definir la estructura de los elementos de trabajo, documentos base y las actividades que deberán realizarse como parte del proyecto. Pros •Team Foundation Server no se limita a la administración de cambios, sino que provee una plataforma completa para administrar el ciclo de vida de software. Esto se traduce en ahorro de dinero y esfuerzo, ya que evitamos la necesidad de integrar varios productos. •Los elementos de trabajo de TFS también se pueden acceder desde Excel o Project. Contras •TFS sólo funciona sobre plataforma Windows. •En algunas evaluaciones y comparativos que encontramos, se maneja que una de las limitaciones de TFS es su escalabilidad, ya que difícilmente soporta más de 500 usuarios concurrentes. Sin embargo, sabemos que para el grueso de las organizaciones en América Latina, esto no es un factor importante, ya que en dicha región, el grueso de las organizaciones de software tienen menos de 50 desarrolladores.

Conclusión Al igual que la mayoría de los productos de Microsoft, TFS es una herramienta amigable y fácil de usar, orientada hacia la productividad, más que a la flexibilidad o la escalabilidad. TFS ofrece una gran relación precio-beneficio, ya que en un producto integrado y fácil de implantar, provee la funcionalidad requerida por la gran mayoría de los equipos de desarrollo de software.

Figura 6. Reportes automáticos listos para usarse

www.softwareguru.com.mx

/*CÁTEDRA Y MÁS*/

// COLUMNA

El arte dinámico de la programación El programador y las herramientas

Dr. Raul A. Trejo es profesor investigador del Instituto Tecnológico y de Estudios Superiores de Monterrey, campus Estado de México. Aunque su área de especialidad es la inteligencia artificial, siempre ha sido un apasionado de la Ingeniería de Software y de la programación en particular. Ha programado en Basic, Pascal, C y sus derivados, pasando por lenguajes más esotéricos como Lisp, Scheme y Prolog, antes de dejarse convencer por la programación orientada a objetos. ASP y C# están en su mira.

n días pasados me encontraba revisando un servicio web que había estado desarrollando con ASPs. Mi atención estaba enfocada al proceso de integrar el servicio al resto del diseño de un portal de Internet, y consultaba un manual del lenguaje mientras verificaba la interfaz de mi código. Fue entonces que reparé en que realmente no soy un experto programador de ASP. Para ser honesto, prácticamente desconozco el lenguaje. Miré con una sonrisa mis 300 líneas de código y me di cuenta de que, de no ser porque estaba usando Web Developer –una herramienta de la compañía de las ventanitas–, probablemente aún estaría escribiendo el cuerpo de mi servicio web, en lugar de ya estar revisando la interfaz. Fue así que empecé a explorar con curiosidad los componentes de mi portal: las líneas de XML, las consultas de SQL embebidas dentro de un código en C++. De hecho, me sentí orgulloso de ese código en C++: creo que escribí personalmente como el sesenta por ciento de él. Yo aprendí a programar en los ochentas. Aprendí a programar con compiladores de línea que arrojaban oscuros mensajes de error, me hice adicto a los ambientes integrados de desarrollo que señalaban el lugar donde (más probablemente) se encontraba el error, sobreviví al fiasco de los llamados lenguajes de cuarta generación y tuve mis dudas con respecto a la programación visual. Y hoy en día trabajo con herramientas WYSIWYG que me permiten diseñar mi portal, mi conexión a servidores y la consulta de datos de un modo visual e intuitivo. He escuchado decir que las herramientas de desarrollo de software han cambiado el rol del programador. Incluso he escuchado argumentos publicitarios con respecto a que los programadores son una especie en extinción. La verdad, yo difiero mucho de estas ideas. El papel del programador, y más en general, el del programador analista, no ha cambiado mucho desde la invención de las máquinas de Von Neumman: el programador analiza un problema, plantea una solución computacional y codifica un algoritmo en el lenguaje de su elección. Ningún algoritmo no trivial está exento de este proceso de análisis y diseño. Así como tampoco

www.softwareguru.com.mx

está exento del debido proceso de verificación y validación, en el que de nuevo el programador juega un importante papel. Como verán, el rol del programador está vivo y coleando: estos algoritmos deben ser necesariamente codificados por un ser humano, línea por línea. Entonces, ¿cuáles son los beneficios que las herramientas de desarrollo le dan al programador? Estos son muchos también: • Facilitan la realización de tareas rutinarias, como generar la conexión al servidor de base de datos, o realizar la apertura de un puerto de HTTP. • Simplifican las tareas tediosas, tales como el formateo de pantallas y reportes. • Automatizan el trabajo repetitivo, como la ejecución de baterías de casos de prueba. • Permiten integrar los diferentes procesos del ciclo de vida de desarrollo de software, con herramientas que, por ejemplo, integran la documentación de casos de uso de un sistema con la creación de las clases que surgen de su diseño. • Facilitan procesos de alta complejidad para el equipo de desarrollo. Un ejemplo claro es el control de configuraciones de software, una tarea verdaderamente titánica sin una herramienta automatizada. Es cierto que aprender a usar estos ambientes requiere de un esfuerzo mayor que los antiguos compiladores (he pasado varias semanas comprendiendo Visual Studio Team System y Rational Architect, y todavía me falta), pero el beneficio a corto plazo para el equipo de programación con una herramienta correctamente utilizada, resulta evidente. He terminado mi código, mi portal está completo. Y mi libro de ASP está sobre la mesa. Debo de aprenderlo. Después de todo, hay programación para rato. —Raul A. Trejo

MAR-ABR 2007

/* ADMINISTRACIÓN DE PROYECTOS */

// PRÁCTICAS

Caso Práctico sobre Análisis de Puntos de Función Parte 1: Introducción y Definición Por Aquiles Santana

n el número de SG de julio-agosto del 2005, mi colega Sergio Durán, describió de manera general el método de Análisis de Puntos de Función, cuyo detalle se encuentra explicado en el Manual de Prácticas de Conteo (CPM por sus siglas en ingles) en la actual versión 4.2. Este manual, se mantiene constantemente por el International Function Points Users Group (IFPUG), con el fin de incrementar la repetitibilidad y reproducibilidad en el conteo de las aplicaciones de software.

Reproducibilidad y repetitibilidad Antes de continuar, recordemos que la repetibilidad, es la variación que tiene una misma persona contando una misma aplicación en tiempos distintos, por otro lado, la reproducibilidad es la variación promedio entre diferentes personas, contando la misma aplicación. En la práctica se ha visto que de aplicarse correctamente el método de Análisis de Puntos de Función, la desviación esperada no será mayor al +/-10%. Esto quiere decir que si una aplicación fuera medida en 100 puntos de función, por un equipo experimentado en Análisis de Puntos de Función en México, cabría esperar que el conteo de la misma aplicación por otro equipo en Brasil, también experimentado en el método, fuera entre 90 y 110 puntos de función. En la práctica, esta situación la he verificado varias veces, contando aplicaciones para diversos clientes, y comprobando mis resultados con otros equipos totalmente independientes dentro y fuera de México. Es esta estandarización y similitud en los resultados, lo que sorprende y convence. El gran atributo que debe proveer una métrica, es la certeza, y la certeza está asociada con la confianza de que la medición será la misma aunque sea realizada por diferentes personas, o en diferentes momentos.

Ahora nos preguntamos, ¿cómo es que este método ha logrado dicha repetibilidad y reproducibilidad en la medición de algo abstracto e inmaterial como lo es el Software? Medir algo físico es sencillo, basta sacar nuestro instrumento de medición, medir y leer el resultado. Al medir la funcionalidad del software, tenemos el problema de que el instrumento de medición, es el mismo ser humano, el cual, por cierto, es un instrumento de medición muy complejo, lleno de ruido, experiencias y percepciones, por lo que la “calibración” de este instrumento se basa en seguir un conjunto de definiciones, reglas, guías y ejemplos de cómo aplicar el método, con el fin de reducir la ambigüedad o interpretación que cada persona pudiera hacer en la aplicación. Es por esto que el Manual de Prácticas de Conteo del IFPUG, está dividido en cuatro secciones: la primera sección incluye las definiciones y reglas de cada uno de los componentes del conteo; la segunda sección provee guías y ayudas para el conteo de ciertas situaciones que causan ambigüedad en el conteo; en la tercera sección se ofrecen una serie de ejemplos que ayudan a entender y acotar los conceptos anteriormente provistos; y por último, la cuarta sección provee un glosario para tener un lenguaje común dentro de la práctica. Adicionalmente, el “instrumento de medición” (la persona que cuenta) es calibrado a través de la práctica y experiencia, siendo la certificación como Certified Function Points Specialist (CFPS), el reconocimiento oficial que otorga el IFPUG a una persona, para garantizar que las mediciones de software son apegadas al estándar, y por lo tanto, la medición será repetible y reproducible. En el presente artículo, realizaremos un ejemplo de cómo el método es aplicado,

para obtener un conteo de puntos de función en una aplicación Web hipotética.

Planteamiento y requerimientos iniciales Una empresa de compra-venta de autos usados, ha decidido incursionar en Internet, ofreciendo el servicio de venta de autos. Para ello ha pedido a una empresa desarrolladora de Software, la ejecución del proyecto, y ha sugerido que el producto sea entregado en 2 meses. Es así que, el administrador del proyecto utilizará los puntos de función para estimar el proyecto, y validar la factibilidad de terminarlo en el tiempo deseado. De antemano, la empresa desarrolladora, prevé que los requerimientos y restricciones no funcionales, serán de complejidad promedio y el desarrollo será realizado en C#. Como parte de los requerimientos funcionales, el cliente ha indicado lo siguiente: 1. Un posible comprador de vehículo podrá acceder a la página Web del distribuidor para conocer el precio y comprar un auto del inventario. 2. La aplicación Web utilizará la información que ya se mantiene dentro del Sistema de Inventario de Vehículos (SIV). Este sistema mantiene los vehículos y los posibles accesorios de cada uno de ellos. El modelo de datos que maneja es el siguiente:

Diagrama 1. Modelo de datos del SIV

Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido responsable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de Función y estimaciones a más de 300 personas en 5 países latinoamericanos y Canadá. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.

MAR-ABR 2007

www.softwareguru.com.mx

“De aplicarse correctamente el método, la desviación esperada no será mayor al +/- 10%”. 3. Un comprador potencial, podrá buscar un vehículo de dos formas: podrá ver todo el inventario, o filtrar con base a una serie de características de los vehículos. La pantalla de consulta será de la forma siguiente:

6. El comprador podrá entonces verificar el listado, y si ve un vehículo que le llame la atención, podrá seleccionarlo y hacer una consulta detallada, la cual se mostrará en la pantalla siguiente:

de la aseguradora, nombre de la financiera, marca del vehículo comprado, modelo, año-modelo, color, accesorios y precio del vehículo. Los datos quedarán almacenados en la siguiente tabla: Compra Número de Compra Número de Serie Vehículo Nombre del Comprador Dirección del Comprador Teléfono del Comprador E-mail del Comprador Nombre de Cia. de Seguros

Pantalla 1. Parámetros de Consulta

Pantalla 3. Detalle del Vehículo

4. Los drop-downs de Año_Modelo, Marca/ Modelo y Accesorios, serán llenados a partir de la información almacenada en el Sistema de Inventario de Vehículos. Adicionalmente, el drop-down de “Rango de Precios” ofrecerá 5 rangos de precio. Cada uno será calculado a partir del valor mínimo y máximo del precio de los autos que se tienen en inventario, y luego, dichos valores serán concatenados para mostrarse de la manera siguiente: •Entre 50,000 y 100,000 •Entre 100,001 y 150,000 •....

7. Si el posible comprador, decide comprar el vehículo, entonces presionará el botón “Comprar”, que lo llevará a la siguiente pantalla, en donde registrará sus datos, los de su aseguradora y los de su institución financiera. Tal y como se muestra en la pantalla siguiente:

Agente de Cia. de Seguros Teléfono de Cia. de Seguros Fax de Cia. de Seguros Nombre Institución Financiera Fax de Institución Financiera

Diagrama 2. Tabla de Datos

Aplicación del proceso de análisis de Puntos Funcionales Planteado el caso práctico, podemos aplicar paso a paso el método de Análisis de Puntos de Función, para lo cual, haremos distinción de definiciones importantes que deben ser consideradas. Este es un proceso largo que veremos a detalle en el siguiente número de SG. Mientras tanto, comparto con ustedes el diagrama que muestra los pasos que estaremos realizando:

5. Con base a los parámetros de consulta, será mostrado un listado con los vehículos disponibles en el inventario. Si no hay vehículos, el mensaje: “No hay vehículos con esas características”, se desplegará. Pantalla 4. Captura de Datos para Compra

Pantalla 2. Listado de Vehículos

www.softwareguru.com.mx

8. Al término de esta operación, presionará el botón: “Salvar”, lo cual hará que el auto seleccionado quede como “comprado” en el inventario de vehículos. La información de compra se guardará en el almacenamiento de compras, y por último, se enviará un correo de confirmación al comprador, informando: el número de compra, nombre del comprador, nombre

Diagrama 3. Proceso de Análisis de Puntos de Función

Nos vemos en el próximo número de SG ...

MAR-ABR 2007

// PRÁCTICAS

/* ARQUITECTURA*/

Evaluando la Arquitectura de Software Parte 2. Métodos de Evaluación Por Omar Salvador Gómez

n el número anterior, dimos a conocer la práctica de evaluaciones a la arquitectura, durante el ciclo de vida del desarrollo de software. Algunos de los puntos que estudiamos fueron: el propósito de valorar los diferentes tipos de evaluación, los roles asociados, y resultados. En esta ocasión, daremos a conocer cuatro métodos que analizan un atributo de calidad específico en la arquitectura de software. Después de explicar cada método, presento una tabla comparativa para brindar una guía rápida hacia cada uno.

Architecture Level Modifiability Analysis (ALMA) El atributo de calidad que analiza ALMA, es la facilidad de modificación. Esto se refiere a la capacidad de un sistema para ser ajustado debido a cambios en requerimientos, o en el entorno, así como la adición de nueva funcionalidad. ALMA es el resultado de los trabajos de investigación realizados por Bengtsson y Lassing [1].

con el propósito de evaluación. Por ejemplo: si la meta es estimar el esfuerzo de mantenimiento, se recomienda seleccionar aquellos escenarios que corresponden a los cambios que tienen una alta probabilidad de que ocurran durante la vida operacional del sistema. 4. Evaluar escenarios. Se realiza un análisis de impacto, que consiste en identificar los componentes afectados por los escenarios previamente definidos, determinar el efecto del cambio sobre los componentes, así como determinar los efectos del cambio en otros componentes. Los resultados de este análisis se deben expresar ya sea de manera cuantitativa o cualitativa. 5. Interpretar resultados. Finalmente se interpretan los resultados, así como las conclusiones del análisis dependiendo de la meta de evaluación seleccionada.

ALMA es un método de evaluación orientado a metas. Existen tres para las que se puede usar: •Predicción del costo de mantenimiento. Consiste en estimar el esfuerzo requerido para modificar la arquitectura a cambios requeridos en un futuro. •Evaluación de riesgos. Identifica los tipos de cambios que pueden ser complejos o que sean inflexibles en la arquitectura de software. •Selección de un conjunto de arquitecturas. Compara dos o más arquitecturas propuestas y selecciona aquella que proporcione mayor soporte a cambios. Figura 1. Método ALMA

ALMA puede utilizarse una vez que concluye la especificación de la arquitectura (evaluación clásica), o aun cuando la arquitectura ya ha sido implementada (evaluación tardía). Este método se apoya en el uso de escenarios de cambio, los cuales describen eventos posibles que provocarían cambios al sistema, y cómo se llevarían acabo éstos. Este método se realiza a través de los siguientes pasos: 1. Definir la meta de evaluación. Dependiendo del objetivo de la evaluación, se selecciona alguna de las tres metas. 2. Describir la arquitectura de software. Se colecta la información más relevante de la arquitectura: sus principales componentes, las relaciones entre éstos, así como las relaciones con el entorno del sistema. 3. Obtener escenarios. Se definen los escenarios de cambio y se agrupan en categorías. Se eligen aquellos escenarios relacionados

Performance Assessment of Software Architecture (PASA) El atributo de calidad que analiza PASA, es el desempeño. Que se interesa por conocer, qué tanto tiempo le toma al sistema de software responder cuando uno o varios eventos ocurren, así como determinar el número de eventos procesados en un intervalo de tiempo dado. PASA es el trabajo resultante de Williams y Smith [2], y utiliza diversas técnicas para la evaluación, tales como la aplicación de estilos arquitectónicos, anti-patrones, guías de diseño y modelos. Al igual que ALMA, PASA se basa en escenarios. Asimismo, puede aplicarse una vez que la arquitectura se ha especificado, o posteriormente, cuando ya ha sido implementada. Los escenarios gene-

Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT). Actualmente es profesor de la Universidad de Guadalajara, es miembro de la Association for Computing Machinery (ACM) y del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org

MAR-ABR 2007

www.softwareguru.com.mx

rados en este método proveen una medida de razonamiento con respecto al desempeño del sistema. Si se requieren análisis más detallados, los escenarios sirven como punto de partida para construir modelos de desempeño.

con los resultados de la evaluación que incluye los objetivos de la evaluación, hallazgos encontrados, pasos específicos a seguir y recomendaciones.

Para utilizar este método, la arquitectura de software debe estar previamente documentada. En caso de que se encuentre parcialmente documentada, es necesario extraer la información faltante de los miembros del equipo, así como de códigos fuente. Los pasos para llevar acabo este método son: 1. Presentar el método de evaluación. Se comunica al equipo y directivos el objetivo de la evaluación, y se explica el método PASA. 2. Presentar la arquitectura. El equipo de desarrollo presenta la arquitectura actual de una manera general y sin entrar en detalles. 3. Identificar casos de uso críticos. Se seleccionan los casos de uso que son importantes para la operación del sistema, así como aquellos que demandan una respuesta de tiempo rápida para el usuario, u otros que presentan algún riesgo de desempeño. Recordemos que un caso de uso puede contener varios escenarios, que describen las diferentes formas en que se puede realizar el caso de uso. Los escenarios se especifican en UML como diagramas de secuencia. 4. Seleccionar los escenarios de desempeño principales. Por cada caso de uso crítico, se debe identificar los escenarios significativos con respecto al desempeño. 5. Identificar objetivos de desempeño. Por cada escenario de desempeño principal, se debe especificar al menos un objetivo de desempeño. Mismos que pueden ser expresados de distintas maneras. Por ejemplo: expresarlos en tiempo de respuesta, capacidad de respuesta, restricciones o utilización de recursos. Para poder medirlo, el objetivo de desempeño debe ser cuantitativo. 6. Clarificar la arquitectura y discutirla. En este paso se estudia más a detalle la arquitectura, por lo que se tienen reuniones con el arquitecto y equipo de desarrollo para aclarar dudas. Si existe información acerca del desempeño del sistema, se colectan métricas. 7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para analizar el desempeño de la arquitectura. Por ejemplo: se identifican estilos arquitectónicos, con la finalidad de detectar efectos negativos en el desempeño, se identifican anti-patrones de desempeño que documentan problemas comunes. Se elaboran modelos de desempeño con el objetivo de identificar problemas en la arquitectura. 8. Identificar alternativas. Si se encontraron problemas de desempeño, se identifican alternativas de solución. Estas pueden incluir el cambio de estilo arquitectónico, modificar la arquitectura para eliminar anti-patrones de desempeño, o alternativas para optimizar la interacción entre componentes. 9. Presentar resultados. Finalmente se elabora un documento

www.softwareguru.com.mx

Figura 2. Método PASA

Las personas involucradas durante la evaluación son: el arquitecto, el equipo de desarrollo y en algunos momentos, el gerente(s) de proyecto. Si se realiza de forma intensiva, la evaluación completa se puede llevar acabo en una semana. PASA se considera un método de evaluación maduro, ya que ha sido probado en varios dominios de aplicación como sistemas web, aplicaciones financieras y sistemas en tiempo real.

Scenario based Architecture Level UsabiliTy Analysis (SALUTA) SALUTA es el primer método desarrollado para evaluar la arquitectura desde la perspectiva de la facilidad de uso del sistema. SALUTA es el resultado de los trabajos de investigación hechos por Folmer y Gurp [3]. Este método hace uso de un marco de referencia elaborado por los mismos autores en el que se expresan las relaciones que existen entre la facilidad de uso y la arquitectura de software [4]. Este marco de referencia incluye un conjunto integrado de soluciones de diseño tales como patrones de diseño y propiedades que tienen un efecto positivo sobre la facilidad de uso en un sistema de software. SALUTA analiza cuatro atributos que están directamente relacionados con la facilidad de uso en un sistema de software, estos son: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Se recomienda efectuar la evaluación una vez que la especificación de la arquitectura ha finalizado, pero antes de que se implemente.

MAR-ABR 2007

// PRÁCTICAS

/* ARQUITECTURA */

Este método se basa en escenarios de uso, los cuales se agrupan en uno o más perfiles de uso. Cada uno representa la facilidad de uso requerida por el sistema de software. SALUTA está compuesto por los siguientes pasos, que se ilustran en la figura 3. 1. Crear perfiles de uso. Se identifican los usuarios y se organizan en categorías. Luego se identifican las tareas más significativas del sistema y el contexto donde será usado el sistema, se determinan los valores para los atributos: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Para reflejar la diferencia en la prioridad de los atributos, se asigna a cada uno un valor numérico no repetido entre 1 y 4. Por último, se seleccionan los escenarios más representativos que tienen mayor prioridad con respecto a sus atributos. 2. Describir la facilidad de uso proporcionada. Se colecta la información de la arquitectura de software para determinar el nivel de soporte en los escenarios de uso. Esto se realiza efectuando un análisis basado en patrones, o basado en propiedades. En ambos análisis se utiliza el marco de referencia para determinar la presencia de patrones o propiedades de facilidad de uso en la arquitectura a evaluar. 3. Evaluar escenarios. Se evalúa cada uno de los escenarios que forman parte del perfil de uso. Por cada escenario se analizan los patrones y propiedades previamente identificados. Se recomienda usar el marco de referencia para analizar cómo un patrón, o propiedad particular afecta a un atributo específico en un escenario de uso. Finalmente, se expresan de manera cuantitativa los resultados del análisis, que indican el grado de soporte de facilidad de uso en cada uno de los escenarios. 4.Interpretar resultados. En este paso se obtienen los resultados de la evaluación, que contienen el grado de facilidad de uso que soporta la arquitectura evaluada.

Figura 3. Método SALUTA

Las personas involucradas durante la evaluación son el arquitecto de software, ingenieros de requerimientos o ingenieros responsables por la facilidad de uso.

MAR-ABR 2007

Survivable Network Analysis (SNA) SNA [5] es un método desarrollado por el CERT (Computer Emergency Response Team) que forma parte del SEI. Este método ayuda a identificar la capacidad de supervivencia en un sistema, analizando su arquitectura. La supervivencia, es la capacidad que tiene un sistema para completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes. Un ejemplo de la definición anterior es la siguiente: un cajero automático debe garantizar al usuario los servicios esenciales aun cuando éste se encuentre en presencia de algún ataque externo o falla interna. SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema: •Resistencia. Es la capacidad del sistema para repeler ataques, fallas o accidentes. •Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes, y si estos ocurren, evaluar los daños. •Recuperación. Es la capacidad de mantener en operación los servicios esenciales en presencia de ataques, fallas o accidentes. Este método puede ser aplicado después de la especificación de una arquitectura, durante la implementación de ésta, o posteriormente. SNA se basa en escenarios de uso, e identifica dos tipos de escenarios. El primer tipo son los escenarios normales, que se componen de una serie de pasos donde los usuarios invocan a servicios y obtienen acceso a activos, tales como bases de datos. El segundo tipo de escenarios son los de intrusión, en los que se representan diferentes tipos de ataques al sistema. SNA está compuesto por los siguientes pasos: 1. Definición del sistema. En este paso se obtiene la misión del sistema, se discute el entorno de uso en términos de capacidades y ubicaciones de los usuarios, se analizan posibles riesgos que el sistema pueda presentar en condiciones adversas, finalmente se analiza la arquitectura de software. 2. Definición de las capacidades esenciales. A continuación se seleccionan los servicios esenciales y los activos que usan. Se deben seleccionar aquellos servicios y activos que sean críticos para garantizar en condiciones adversas, la misión del sistema. Una vez seleccionados, estos se trazan a través de la arquitectura, para identificar los componentes que participan en proporcionar los servicios esenciales. 3. Definición de las capacidades que comprometen al sistema. En este paso se selecciona un conjunto representativo de posibles ataques, basados en el entorno de operación del sistema. Se definen los escenarios de intrusión y se trazan a través de la arquitectura, para identificar componentes que comprometan la supervivencia del sistema, logrando así el acceso y daño a éste. 4. Analizar la supervivencia. Finalmente se identifican los escenarios de intrusión que contienen los componentes esenciales y que comprometen la supervivencia del sistema. Por cada componente identificado se procede a analizarlo en términos de las capacidades de resistencia, reconocimiento y recuperación. Estos análisis se colocan en una tabla llamada: mapa de supervivencia, que contiene por cada escenario de intrusión, las estrategias de supervivencia actuales y las recomendadas con respecto a cada una de las capacidades.

www.softwareguru.com.mx

la facilidad de uso; y SNA, que analiza en la arquitectura, la supervivencia de un sistema ante la presencia de ataques, fallas o accidentes. La Tabla 1 presenta a manera de resumen, un cuadro comparativo entre estos cuatro métodos de evaluación.

Referencias

Figura 4. Método SNA

El resultado que se obtiene al final de la evaluación, es un documento que incluye modificaciones recomendadas a la arquitectura, acompañadas del mapa de supervivencia. Las personas involucradas durante la evaluación son: el arquitecto de software, el diseñador principal, los propietarios del sistema y usuarios del mismo.

Conclusiones En esta segunda parte hemos presentado el método de evaluación ALMA, que se interesa por predecir la facilidad de modificación en una arquitectur. PASA, que analiza en la arquitectura el desempeño del sistema. SALUTA, que analizando una serie de atributos de calidad predice

1. Bengtsson, PerOlof, Nico Lassing and Jan Bosch, Vliet, Hans van. “Architecture-Level Modifiability Analysis (Alma).” The Journal of Systems and Software 69 (2004): 129-147. 2. Williams, Lloyd G. and Connie U. Smith. “PASASM: A Method for the Performance Assessment of Software Architecture.” Paper presented at the Proceedings of the 3rd Workshop on Software Performance, Rome, Italy 2002. 3. Folmer, Eelke, Jilles van Gurp and Jan Bosch. “Scenario-Based Assessment of Software Architecture Usability.” Paper presented at the Proceedings of Workshop on Bridging the Gaps Between Software Engineering and Human-Computer Interaction, ICSE, Portland 2003. 4. Eelke Folmer, Jilles van Gurp and Jan Bosch. Investigating the Relationship Between Usability and Software Architecture, Software process improvement and practice: Wiley, 2003. 5. Mead, Nancy R., Robert J. Ellison, Richard C. Linger, Thomas Longstaff and John McHugh. “Survivable Network Analysis Method.” CMU/SEI, 2000.

ALMA

PASA

SALUTA

SNA

Meta

Predecir el costo de mantenimiento, evaluar riesgos, comparación entre arquitecturas.

Analizar la arquitectura con respecto a los objetivos de desempeño de un sistema.

Predecir la facilidad de uso en un sistema analizando la arquitectura.

Identificar la capacidad de supervivencia en un sistema ante la presencia de ataques, fallas o accidentes.

Atributo de calidad

Facilidad de modificación

Desempeño

Facilidad de uso

Supervivencia

Técnica de evaluación

Escenarios de cambio

Escenarios

Escenarios de uso

Escenarios de uso normales, escenarios de intrusión.

Entradas

Especificación de la arquitectura, requerimientos no funcionales.

Especificación de la arquitectura.

Especificación de la arquitectura, requerimientos no funcionales relacionados con la facilidad de uso.

Especificación de la arquitectura

Salidas

Dependiendo de la meta de evaluación se generan los resultados.

Hallazgos encontrados, pasos específicos a seguir y recomendaciones.

Grado de facilidad de uso que soporta la arquitectura evaluada.

Modificaciones recomendadas a la arquitectura y mapa de supervivencia.

Personas involucradas

Arquitecto y equipo de desarrollo

Arquitecto, equipo de desarrollo y administradores del proyecto.

Arquitecto, ingenieros de requerimientos o ingenieros responsables por la facilidad de uso.

Arquitecto, diseñador principal, propietarios del sistema, usuarios.

Duración

No especificado

7 días

No especificado

Validación del método

Sistemas de control embebido, sistemas médicos, telecomunicaciones, sistemas administrativos.

Sistemas basados en Web, aplicaciones financieras y sistemas en tiempo real.

Algunos casos de estudio que incluyen principalmente sistemas Web.

Sistemas comerciales y de gobierno.

Tabla 1. Cuadro comparativo entre los métodos de evaluación ALMA, PASA, SALUTA y SNA

www.softwareguru.com.mx

MAR-ABR 2007

// PRÁCTICAS

/* ESTRATEGIAS DE DESARROLLO */

Desarrollo Dirigido por Modelos Un Nuevo Paradigma de Desarrollo Por Sergio Cedillo

l desarrollo dirigido por modelos o MDD (por sus siglas en inglés), es una mejora importante en las prácticas de desarrollo, que habilita a los sistemas de TI para ser más correspondientes con las iniciativas de negocio. Con MDD, se puede mejorar la consistencia y la calidad de las soluciones, al automatizar patrones de implantación con transformaciones para eliminar trabajo repetitivo y de bajo nivel en el desarrollo. Este artículo da una introducción a MDD, y posteriormente, ahonda en la forma en que éste se lleva acabo.

En MDD se introduce el criterio adicional de que un modelo debe ser interpretado por una máquina. Por ejemplo: debemos ser capaces de acceder al contenido del modelo de manera automática. Esta capacidad de interpretación de los modelos es un prerrequisito para ser capaces de generar artefactos. Un diagrama en un pizarrón podría reunir otros criterios para ser considerado un modelo, pero mientras no pueda ser interpretado por una máquina, no podrá ser usado dentro de una cadena de MDD.

El ambiente de negocios actual

Los modelos de software se expresan típicamente en el lenguaje UML, que como sabemos, es un lenguaje para especificar, visualizar y documentar sistemas de software. Provee una notación visual y una semántica subyacente para modelos de software. UML también tiene un formato de serialización estándar, legible para una computadora, que le permite su automatización.

Los sistemas de TI no se desarrollan en aislamiento. Su propósito es facilitar las operaciones de un negocio, lo cual implica que las necesidades del ambiente de negocio determinan la manera como se desarrollan los sistemas de TI que lo soportan. La siguiente lista describe los principales motivadores del ambiente actual: •Así como se espera que los negocios sean más flexibles y adaptables, de la misma manera ocurre para los sistemas de TI. •Los días de invertir en TI simplemente porque sí, son cosa del pasado. Los departamentos de TI ahora operan bajo fuertes restricciones de presupuesto y se espera que demuestren un claro valor al negocio. •Los sistemas de software continúan creciendo en escala y complejidad para satisfacer las necesidades del negocio. Las técnicas que funcionan bien para desarrollos de pequeña escala, no necesariamente escalan para iniciativas de nivel empresarial. •La sofisticación de las plataformas de TI actuales requieren de gente altamente especializada, y las organizaciones sufren para encontrarlos. Además, los proyectos con frecuencia dependen de personas clave y sufren significativamente cuando éstos dejan la compañía. •Existe una gran variedad de plataformas de Middleware, y el ritmo con el que evolucionan no parece detenerse. Las organizaciones quieren aprovechar los avances en Middleware, pero no quieren reescribir constantemente sus aplicaciones.

Entendiendo la estrategia dirigida por modelos MDD es un estilo de desarrollo donde los principales artefactos de software son modelos, a partir de los cuales se puede generar código y otros artefactos. Un modelo es una descripción de un sistema desde una perspectiva particular, omitiendo detalles irrelevantes, así las características de interés se vuelven más evidentes. Por ejemplo, un ingeniero civil crea un modelo de un edificio que le sirve para determinar las posiciones de las cargas.

Los modelos de software esconden detalles de implantación técnica, para que un sistema pueda diseñarse utilizando conceptos de un dominio de aplicación. El diseño de la aplicación, típicamente se lleva acabo utilizando una herramienta de modelado de UML (como por ejemplo IBM Rational Software Architect), para modelar conceptos relevantes al dominio de la aplicación. Por ejemplo: cuando se trabaja en un dominio de integración empresarial, arrancaríamos modelando el diseño de la aplicación utilizando conceptos tales como mensaje, proxy y adaptador. Posteriormente se puede refinar el modelo de software y diseñar los detalles de sus componentes.

Los modelos como borradores y planos La utilización de modelos para diseñar software, ya es una práctica bien establecida. Sin embargo, en la mayoría de los casos los modelos se utilizan sólo como borradores que comunican de manera informal algún aspecto del sistema, o como planos arquitectónicos que describen un diseño que posteriormente se implementa a mano. Esta práctica de utilizar modelos como documentación y especificación es valiosa, pero requiere una disciplina estricta para mantenerlos actualizados conforme la aplicación progresa y cambia con el tiempo. Conforme avanza un proyecto y hay cambios y presiones por los tiempos de entrega, es muy común que se actualice la implementación (código), sin actualizar los modelos. Ciertamente, un modelo impreciso puede ser incluso más peligroso que la ausencia de uno.

Sergio Cedillo es Especialista Rational en IBM de México, y cuenta con más de siete años de experiencia en productos y soluciones de Rational. Previamente trabajó como consultor en soluciones de middleware para mercados financieros. En los últimos años se ha especializado en soluciones de pruebas automatizadas, y en implantaciones del Proceso Unificado Rational. Sergio es Ingeniero en Electrónica con Especialidad en Computación por la Universidad Autónoma Metropolitana.

MAR-ABR 2007

www.softwareguru.com.mx

Los modelos como habilitadores de la automatización En MDD, los modelos no son solamente borradores, diagramas o planos, sino artefactos primarios, de los cuales se genera automáticamente una implementación. En MDD, los modelos orientados al dominio de la aplicación son el foco principal cuando se desarrollan nuevos componentes de software. El código y otros artefactos se generan utilizando transformaciones diseñadas con entradas provistas tanto por expertos en modelado, como por expertos del dominio.

No sólo código La generación de código y otros artefactos de la plataforma son parte importante de MDD, pero la automatización mediante MDD puede ir mucho más allá. Un proyecto de desarrollo de software necesita producir muchos artefactos, además del código, algunos de los cuales, pueden ser completa o parcialmente derivados a partir de los modelos. La siguiente lista muestra algunos de ellos, sin embargo, pueden existir más, tales como documentación, artefactos de pruebas, scripts de construcción y liberación, otros modelos y uso de patrones.

¿Cómo desarrollar un proyecto con MDD?

Figura 1. Pasos para desarrollar un ambiente MDD

MDD tiene un gran impacto en la forma en la que desarrollamos software. Captura las decisiones de la gente técnica más apta, haciéndolas disponibles al resto del equipo mediante las herramientas personalizadas para las necesidades del proyecto. Esto genera ahorros significativos en el costo del desarrollo y pruebas del software, ya que gran parte de la codificación de bajo nivel se automatiza. Adicionalmente, el número de errores se reduce, y se incrementa la consistencia en la forma como se realiza el trabajo.

Se puede construir el ambiente y herramientas MDD, previo al desarrollo de la aplicación de negocio, o se puede tomar un método más iterativo, o “justo-a-tiempo”, donde se desarrolla el ambiente MDD en paralelo a la aplicación. De cualquier manera, es importante asignar tiempo adicional al proyecto de la aplicación de negocio, tomando en cuenta las mejoras. Desarrollar mejoras que pudieran identificarse dado el primer uso de las herramientas.

No obstante, con MDD también cambia la manera en que se lleva a cabo el proyecto, dado que se deben llevar a cabo dos proyectos, uno dentro de otro: el proyecto externo que consiste en desarrollar la aplicación de negocio; y otro interno que consiste en desarrollar el ambiente y herramientas MDD que sustentarán el desarrollo del proyecto externo. Típicamente, una aplicación de negocio será identificada como el primer proyecto a ser construido con el ambiente MDD, y después, este ambiente y herramientas, se pueden aprovechar para construir otras aplicaciones de negocio. El diagrama mostrado en la figura 1 muestra el flujo de tareas que se realiza en un proyecto MDD. Las tareas sombreadas serían realizadas en un proyecto tradicional. Las tareas en blanco son las adicionales que construyen las herramientas MDD para un proyecto específico.

www.softwareguru.com.mx

Tareas Los pasos iniciales para desarrollar herramientas MDD son los mismos que en cualquier método de desarrollo tradicional. El arquitecto de la solución, los realiza, y define la estructura de alto nivel de la aplicación de negocio. •Crear la arquitectura de la solución. Definir la estructura conceptual de la aplicación de negocio. Esta se expresa a través de estilos arquitectónicos que los desarrolladores adoptarán al construir la aplicación. •Definir ambientes de ejecución. Se define el ambiente de ejecución en el que correrá la aplicación de negocio. Esto incluye los ambientes de desarrollo, pruebas y preproducción. Una vez que esos dos pasos se completaron, el arquitecto tiene un buen entendimiento de lo que debe desarrollarse para la aplicación del negocio. Aquí ya puede arrancar las tareas específicas de MDD:

MAR-ABR 2007

// PRÁCTICAS

/* ESTRATEGIAS DE DESARROLLO */

“En MDD, los principales artefactos son modelos, a partir de los cuales se puede generar código y otros artefactos”. •Identificar los estándares y patrones comunes. Se identifican los patrones que se repiten durante la solución. •Identificar activos existentes MDD reutilizables. Se comparan los patrones encontrados, con los activos MDD existentes para ver cuáles se pueden reutilizar, o hacer los ajustes necesarios. •Definir el modelo de diseño. Se define qué diagramas, y con qué lineamientos se utilizarán para el modelado. •Identificar un modelo independiente de la ejecución para los componentes. Este modelo especifica los componentes de la aplicación, sin atarse a una forma de desarrollo, o ambiente de ejecución particular. •Producir artefactos muestra. Se codifican manualmente los artefactos para realizar un escenario típico de la aplicación. Esta tarea debe ser realizada por el mejor programador, ya que los programas que genere son los que se utilizarán como base para las plantillas y transformaciones MDD. •Definir la cadena de herramientas. Se identifican las herramientas y configuraciones MDD que se requieren para el proyecto. Una vez que se definen las herramientas MDD necesarias, podemos enfocarnos en construirlas y configurarlas: •Extraer plantillas de artefactos muestra. Se desarrolla una plantilla para cada tipo de artefacto diferente, basándose en los artefactos muestra desarrollados previamente. •Diseñar, codificar y probar transformaciones y patrones. Para cada patrón o transformación, se escribe el código que lea los modelos y genere o actualice los artefactos correspondientes, utilizando las plantillas. •Empacar las herramientas MDD. Las herramientas se empaquetan de forma que sean fácilmente instalables por el equipo de desarrollo. En algunos casos, incluso sería justificable empaquetar las herramientas como un plug-in para el IDE que utilice el equipo, como por ejemplo: Eclipse. •Producir documentación y educación para los desarrolladores de la aplicación. •Validar la cadena de herramientas utilizando escenarios clave. Ahora las herramientas MDD están listas para que los desarrolladores de la aplicación las utilicen. Lo que sigue es entrenar a los desarrolladores de la aplicación para utilizar las herramientas, y entonces desarrollar las aplicaciones de negocio.

La cadena de herramientas MDD La figura 2 muestra el flujo de cómo un desarrollador puede utilizar las herramientas MDD para desarrollar parte de una aplicación de negocio. En este ejemplo, el desarrollador revisa el problema de negocio y selecciona un patrón de diseño. Esto aloja un modelo de diseño, y el desarrollador llena en detalle las funciones específicas del negocio que está construyendo. Posteriormente, el proceso de desarrollo es completamente automatizado. El desarrollador selecciona una opción para generar los artefactos, los cuales son empaquetados y colocados en el área de construcción. Entonces, el desarro-

MAR-ABR 2007

llador puede seleccionar opciones, posteriormente para generar los artefactos adicionales para una plataforma de ejecución particular.

Figura 2. La Cadena de Herramientas MDD

Conclusión En este artículo se explicó cómo se puede utilizar MDD para entregar valor de negocio mejorado de las soluciones de TI. Como cualquier otra técnica o herramienta, MDD se puede usar correcta o incorrectamente. MDD tiene el potencial para producir grandes beneficios como incremento en la productividad, repetibilidad, sistemas más adaptables, mejor comunicación, y captura del conocimiento. Sin embargo, la estrategia debe aplicarse correctamente para asegurar los resultados positivos.

Este artículo es una traducción resumida de un artículo escrito por Larry Yusuf, Mandy Chessell, y Tracy Gardner, y publicado en IBM Developerworks. La versión original se encuentra disponible en: http://www-128.ibm.com/developerworks/library/ar-mdd1

www.softwareguru.com.mx

// UML

Componiendo lo Descompuesto Diagrama de Estructura Compuesta Por Sergio Orozco

En el mundo real –el mundo de los objetos–, es muy común encontrarnos con objetos que están compuestos por más objetos. UML nos permite modelar dicha información por medio de relaciones de composición entre los objetos contenedores y sus partes. Tal relación se muestra tradicionalmente como una asociación entre el contenedor y la parte, con un diamante relleno en la orilla del contenedor. En el siguiente diagrama de la Figura 1 podemos ver que, un carro tiene un motor, y el motor no puede ser parte de otro carro en un momento determinado en el tiempo.

Figura 1.

Modelar de esta forma la composición de objetos puede ser complejo en ciertas situaciones, como en el caso de un carro, y un barco compuestos por un motor; donde para el primero, el motor ayudara a mover las ruedas delanteras, y en el segundo caso, el motor sirviera para mover el propulsor del barco. Para lo que habría que realizar un modelo complejo para aclarar que había una diferencia entre el motor que tenía el carro y el motor del barco.

Figura 2.

El diagrama anterior de la Figura 2 intenta explicar esto, pero tiene deficiencias, pues aunque aclara con la multiplicidad de las conexiones de carro y barco (0..1) como contenedores del motor, que sólo puede estar la instancia del motor en uno de los dos; por otra parte, parece decirnos que el motor del carro puede mover tanto propulsor como llantas. Lo cual es equivocado, pues el motor del barco sólo mueve el propulsor, y el del carro, sólo mueve sus llantas. Tampoco aclara que las dos llantas que mueve el motor en el carro son las delanteras, y no las dos traseras. Para modelarlo correctamente en un diagrama de clases, tendríamos que elaborar toda una jerarquía de herencia entre clases, para distinguir entre los motores de barcos y carros; y entre las llantas delanteras y traseras de un carro, o marcando dependencias entre las relaciones. Esto se muestra en la figura 3.

Figura 3.

Agregando contexto en UML 2 Con UML 2, ahora contamos con un nuevo diagrama, llamado diagrama de estructura compuesta, que nos permite contextualizar las partes que componen a una clase. Así podemos armar un diagrama donde aclaremos que, el carro tiene un motor que mueve las dos llantas delanteras (pero, no las traseras ni el propulsor), y otro diagrama del mismo tipo que, nos permitiría mostrar el barco con un motor que exclusivamente mueve su propulsor (y no las llantas).

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, PM y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de REP del PMI. info@milestone.com.mx www.milestone.com.mx

MAR-ABR 2007

www.softwareguru.com.mx

“La composición es un tipo especial de asociación entre un todo y sus partes”.

El contexto lo define la clase contenedora, que con fines de este ejemplo, serían el carro o el barco. Y dentro de dicha clase, modelamos las partes que lo componen, como se muestra a continuación en la Figura 4. Cada uno de estos diagramas muestra la estructura interna de una instancia de carro y de barco, respectivamente.

Figura 4.

En este caso nos queda mucho más claro que cada uno tiene un motor, pero que funciona de manera diferente. Incluso es claro que el motor del carro mueve exclusivamente las dos llantas delanteras, y no las dos traseras.

indica los objetos que conforman al objeto principal. Ejemplo: el motor y las llantas en el carro, o el motor y el propulsor en el barco. Si se coloca una parte dentro de una clase, significa, en un diagrama de clases: que la clase contenedor tiene una relación de composición con dicho elemento. •Conector. Indica la relación entre las parte internas de la clase que se analiza. •Puertos. Se pueden mostrar puertos para indicar la entrada o salida de una parte hacia otra parte. Se muestran como pequeños cuadrados al final de un conector entre dos partes. No son obligatorias, pero son recomendables si se quiere encapsular el funcionamiento de las partes. Un uso adicional que se puede dar a los diagramas de estructura compuesta, es para mostrar las partes que colaboran, por ejemplo: en un caso de uso. Aunque en esta ocasión no explicaremos dicha perspectiva, consideramos importante mencionarlo, y mostrar una pequeña muestra.

Figura 5.

Los elementos que tradicionalmente se muestran en este tipo de diagrama son: •Clase. Para mostrar la parte de la cual se ilustra su composición interna (ejemplo: carro o barco). •Parte. Se muestra con un rectángulo, e

www.softwareguru.com.mx

En el ejemplo de la Figura 5 podemos ver que, son tres las clases que colaboran en el caso de uso “participar en curso”: el estudiante, el curso y el seminario. Esta forma nos permitiría modelar patrones de diseño indicando los roles que juega cada clase, en la colaboración.

ENE-FEB 2007

// COLUMNA

/*TENDENCIAS EN SW*/

El Futuro TI está en el Consumidor Final Estimulando la Imaginación

Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

a industria global de software en 2006 fue estimada por Microsoft en 131 billones de dólares. El total de la industria de publicidad global es de 580 billones de dólares. Permítame, estimado lector, antes de hablar de bits y bytes, abundar en las importantes “señales” referentes al crecimiento del sector.

Creciendo el sector TI El mercado empresarial se encuentra cada día más saturado. Lo que hemos visto en los últimos años es que, el crecimiento de la industria de software reside principalmente en las siguientes oportunidades: •Incrementar la penetración en PYMES. •Convertir a nuevos usuarios (varios billones a nivel mundial). •Incrementar la adquisición de equipos en el hogar. Con la excepción de Google, las empresas de software han puesto poca atención en el potencial de los ingresos por concepto de publicidad. Se estima que en el periodo 2006-2009, el gasto global en publicidad en línea crecerá de 27 a 51 billones de dólares.

Factores clave de crecimiento Hay un fuerte movimiento monetario de la publicidad tradicional, a la publicidad en línea. Esto se debe a la efectividad del targeting altamente dirigido. La publicidad en línea se puede dividir en 3 rubros primarios: •Búsqueda (45%). •Redes de anuncios (40%). •Otros, como por ejemplo: correo electrónico (15%).

MAR-ABR 2007

Capitalizando la oportunidad Hoy la publicidad en línea representa sólo 5% del mercado total; si pudiéramos crecer en 2007 a 8%, se estarían captando 15 nuevos billones de dólares. Querámoslo o no, esto traerá consecuencias inmediatas: a)Las plataformas que permitan cobrar en línea, intercambio de anuncios, integración de publicidad a sitios de Internet y otros mecanismos que permitan monetizar los sitios de Internet tendrán un gran auge. b)En la búsqueda las oportunidades continúan siendo amplias: •Entregar respuestas directamente al ejecutar la búsqueda y no ligas a los usuarios. •Responder preguntas complejas. Hoy el 40% de consultas complejas no son respondidas. •Entender la intención del usuario. Las palabras tienen diferentes significados con resultados diversos. •Ámbito limitado. La búsqueda al interior de las aplicaciones es muy limitada. •Falta de control de usuario. Poca capacidad de personalización.

Conclusiones El poder reside cada vez más en los usuarios individuales y no en las organizaciones: •El colectivo no sólo crea contenidos que difícilmente una sola empresa podría producir (v.gr. YouTube) y se basa fuertemente en modelos de publicidad en línea. •Los usuarios podrán seleccionar dispositivos para crear redes que no requerirán operadores de infraestructura. (v.gr. Meshup networks que el usuario selecciona y no lo que los corporativos imponen). •El software quedará fuera del alcance de la organización (v.gr. usuarios de oficina haciendo llamadas gratuitas con Skype). Se estima que el 20% a 30% de usuarios instalan este tipo de productos, aunque la política lo impida. Creo que lo más sabio será no oponerse a la corriente, sino montarse y ser impulsado por la oleada. El momento es hoy.

Para conocer más •http://adlab.msn.com •http://it.slashdot.org/article.pl?sid=06/12/20/0227259 •www.wikinomics.com — Luis Daniel Soto

www.softwareguru.com.mx

// FUNDAMENTOS

Ingeniería Web

Las Aplicaciones Web También Requieren Ingeniería Por Noé Huerta y Lacendi Nolasco

Hace ya por lo menos diez años, ellos piensan que su mundo es realmente difela Web irrumpió en nuestras vi- rente, y que los enfoques de ingeniería de softdas. Son ya muy lejanos aquellos ware convencionales no aplican para ellos”. tiempos en los que la web, no era mas que un repositorio de páginas Es de esta necesidad de una estrategia sistemáestáticas que servían como carta tica, pero que tome en cuenta las características de presentación a las empresas, especiales del web, que surge la denominada: Web. San Murugesan la define como y personas. Hoy en día, la web es Ingeniería la aplicación de un enfoque sistemático, disciescencialmente una plataforma plinado y cuantificable para el desarrollo exitopara todo tipo de aplicaciones, con so de aplicaciones web de alta calidad. todo tipo de propósitos: desde tiendas virtuales hasta redes sociales. ¿Qué particularidades tiene el desarrollo web?

Desde su inicio, nos hemos dado cuenta que el desarrollo web tiene características particulares. Por ejemplo: requiere un énfasis especial en la usabilidad, el desempeño, la seguridad y la soportabilidad. Adicionalmente, con la web, han surgido nuevas tecnologías que la habilitan (HTML, JavaScript, XML, ASP, PHP, JSP, JSF, RoR, y la lista continúa...). Esta situación de encontrarnos con una plataforma con características especiales y nuevas tecnologías, sirvió de pretexto para que muchos desarrolladores web dijeran: “aquí no aplica la ingeniería de software”, y se lanzaran a desarrollar aplicaciones como Dios les dio a entender.

Se reconoce que las aplicaciones web tienen sus particularidades, y por ello deben recibir especial atención en algunos puntos, pero esto no significa que deban ignorar por completo la ingeniería. Entre las particularidades más significativas podemos listar: •Residente en red. Una aplicación web reside en una red, y debe dar servicio a una comunidad diversa de clientes. •Inmediatez. Se refiere al corto tiempo que normalmente tienen los proyectos web para terminar, o por lo menos, lanzar una versión inicial. •Evolución continua. A diferencia del soft-

ware de aplicaciones convencional, que evoluciona a través de versiones planeadas y cronológicamente espaciadas, las aplicaciones web están en constante evolución, y se actualizan gradualmente. •Seguridad. Dado que no controlamos con certeza quién puede acceder a nuestra aplicación; la seguridad y confidencialidad de la información requieren un énfasis especial. •Estética. Es bien sabido que la primera impresión jamás se olvida, por lo que nuestro sitio debe ser atractivo, ergonómico y usable. •Medible. Mediante la cuantificación de resultados, podemos conocer la cantidad de usuarios que tenemos, así como sus patrones de comportamiento.

Atributos de calidad en la web ¿Cómo saber que nuestro sitio web es de calidad? No existe una receta mágica que nos dé una respuesta a esta pregunta. Sin embargo, el uso de metodologías, buenas prácticas y la experiencia, son un gran escalón para acercarnos en lo posible a lo que los usuarios definen como calidad. La figura 1 presenta un árbol de requisitos de calidad para aplicaciones web, que fue sugerido por L. Olsina en 1999:

De hecho, Roger Pressmann en su libro: “Software Engineering: A Practitioner’s Approach”, que es una de las biblias de la ingeniería de software, comenta lo siguiente: “Cualquier producto o sistema importante es merecedor de recibir una ingeniería. Esto significa que hay que entender el problema, diseñar una solución viable, implementarla de una manera sólida y comprobarla en profundidad. Probablemente también se deberían controlar los cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del resultado final. Muchos de los que desarrollan en web no opinan lo mismo;

Figura 1. Requisitos de calidad para aplicaciones web

Lacendi Nolasco Calderón es Ingeniero en Desarrollo de Software egresado de la Universidad Madero. Ha sido ponente en Congresos de Software y Ciencias de la Tierra en Puebla y Puerto Vallarta, y organizador del Congreso “Tendencias y Aplicaciones en los Sistemas de Software”. Actualmente se especializa en proyectos de ingeniería web. Noé Huerta Ramírez es Ingeniero en Desarrollo de Software, egresado de la Universidad Madero. Noé se desempeña como consultor independiente, y ha trabajado en diversos proyectos orientados a la ingeniería web, principalmente implantando soluciones basadas en software libre.

MAR-ABR 2007

www.softwareguru.com.mx

“El beneficio del uso de la ingeniería web es que se asegura la correcta ejecución y terminación de cada proyecto.” El proceso de ingeniería web Como ya vimos, las aplicaciones web tienen sus particularidades, y por lo tanto, requieren de un proceso que las tome en cuenta. Es así que, una de las principales características que se debe cumplir para ingeniería web, es que sea iterativo e incremental. Esto como respuesta a la continua evolución de las aplicaciones web, así como el corto tiempo en el que normalmente se requiere que sean implementadas. En su libro anteriormente mencionado, Pressman sugiere un proceso de ingeniería web compuesto por las siguientes fases: •Planteamiento y formulación. Identificamos los objetivos de nuestra aplicación, y delimitamos el alcance de la primera iteración. •Planificación. Una vez planteado el problema, podremos estimar costos, riesgos y esfuerzo durante el desarrollo. Recordemos que en la planeación iterativa solamente se detalla la iteración actual, y las iteraciones subsecuentes sólo se plantean de forma general. •Análisis. Durante esta etapa establecemos los requerimientos técnicos, gráficos, y de contenido, que incorporaremos en la iteración. •Ingeniería. La actividad de ingeniería incorpora dos grupos de tareas que se realizan en paralelo: el diseño del contenido y la producción, se enfocan en el diseño, producción y adquisición del contenido de texto, gráfico y video que se vayan a integrar en la aplicación. Estas tareas son realizadas por personal no técnico. Por otro lado, están el diseño arquitectónico, de navegación e interfaz, el cual lidia con los aspectos técnicos. •Generación de páginas y pruebas. Se prueba que el contenido dinámico se genere correctamente, utilizando las plantillas, interfaces y contenidos diseñados en la fase de ingeniería. Posteriormente se realizan las pruebas pertinentes, que dependerán del tipo de aplicación y requerimientos no funcionales (por ejemplo, pruebas de desempeño, etcétera). •Evaluación del cliente. Al final de cada iteración se debe realizar una evaluación con el cliente, para validar el avance y de-

www.softwareguru.com.mx

terminar los cambios o mejoras –en caso de ser necesarios–, que se aplicarán en las siguientes iteraciones.

entre una aplicación común de software y una Webapp.

Figura 2. Modelo del Proceso IWEB

No reinventar la rueda Una regla de oro en el desarrollo de cualquier tipo de aplicación es: “no reinventar la rueda”. Tal vez algo que agregaríamos al proceso sugerido por Pressmann, sería incorporar actividades específicas para evaluar cuáles de los componentes que ya existen se pueden reutilizar. Esto es porqué en el ambiente web existen muchos frameworks y engines que se pueden adaptar fácilmente a nuestras necesidades. Por ejemplo: prácticamente todos los websites y portales modernos utilizan un CMS (Content Management System). Así que antes de lanzarnos a desarrollar desde cero, echemos un vistazo a los elementos existentes tanto dentro como fuera de nuestra organización.

Conclusiones La ingeniería web se ha convertido en una necesidad para el desarrollo de aplicaciones web de alta calidad. Es imprescindible comentar las características particulares con las que estos sistemas cuentan, como son la inmediatez y la evolución; ya que de esta manera podemos notar la diferencia

El manejo del principio de ingeniería nos evita enfrentar un caos durante nuestro proceso del IWEB, recalcando que nuestra actividad como ingenieros es la formulación, planificación, análisis y diseño; lo que nos conlleva a que cada integrante del equipo multidisciplinario implicado, desempeñe su labor individual y fundamental para el cumplimiento de los objetivos generales.

Referencias •San Murugesan, Athula Ginige. Web Engineering: Introduction and Perspectives. Capítulo 1 del libro, “Web Engineering: Principles and Techniques”. Idea Group Publishing, 2005. •Roger Pressman. “Software Engineering: A practitioner’s perspective”. McGraw-Hill, 2004 •Luis Olsina. “Specifying Quality Characteristics and Attributes for Websites.” Proceedings of 1st Workshop on Web Engineering. ACM, 1995

MAR-ABR 2007

// INFRAESTRUCTURA

Encripción de Datos La última Línea de Defensa Por Roberto González

Los datos son un activo de vital importancia para las empresas modernas. De hecho, cada vez encontramos más y más empresas cuyo negocio central gira alrededor de los datos. Por otra parte, el valor de éstos aumenta día con día, así como las diversas maneras de ganar acceso a ellos. El valor de la información lo define uno mismo, y no es necesario que el dato sea una fórmula matemática que hará evolucionar nuestra vida cotidiana y ganar millones de dólares. Podría ser simplemente, una carta de amor o una fotografía comprometedora que no nos gustaría que nadie mas que el propietario, pudiera tener acceso a ello. En el presente, las amenazas comunes incluyen el extravío de dispositivos portátiles, robo de PCs, laptops, y servidores; también el robo de información cuando los discos se desechan. El riesgo y severidad del robo de datos está en aumento, debido a cuatro factores predominantes: •El aumento del valor de la información almacenada en PCs. •El aumento en el uso de laptops fuera de los perímetros de seguridad de la red. •El aumento masivo de la cantidad de datos almacenados. •Los esfuerzos progresivos y la pericia de los ladrones de información. Estos factores, junto con el creciente número de abusos publicados, están motivando la creación de más regulaciones concernientes a la protección y privacidad de la información. La mayoría de las soluciones de protección, se basan en la idea de proteger el perímetro. Sin embargo, proteger el perímetro no es suficiente, ya que no resuelve algunos casos específicos comunes, tales como:

•La información que se acarrea en dispositivos portátiles. •Cuando el ataque viene desde adentro de la empresa.

dría atreverme a decir que, muy pocos llegan mas allá de eso y, a partir de aquí, se deriva la pregunta: ¿tienen protegida el alma del negocio, “los códigos fuente”?

De acuerdo a la CSI/FBI (Computer Cryme and Security Survey del FBI), el hurto de la información propietaria es una de las formas más costosas de delito informático y, día a día su incremento es en altos porcentajes, añadiéndole a esto, el daño continuo causado por los virus de computadora.

La solución: criptografía

Otras investigaciones revelan que: 82% de los negocios creen que los dispositivos de almacenamiento móviles (tales como memorias USB) son una amenaza significativa de seguridad. Al mismo tiempo, los encuestados admiten que no pueden controlar o supervisar el uso de estos dispositivos.

La criptografía es una técnica eficiente utilizada desde siglos atrás para proteger la información usada en un inicio, para fines bélicos; técnica que ha ido evolucionando con el paso de los años. La criptografía actual utiliza algoritmos matemáticos que se aplican al dato, impidiendo su lectura (en caso de no ser el propietario de la información), y utilizan llaves de encripción y decripción para tal efecto.

Últimamente, los crackers utilizan una técnica de: “secuestro de información” de computadoras conectadas en Internet; lo que hacen, es llevarse toda la información almacenada en ellas, o la encriptan, y si el propietario desea recuperarla, tendrá que pagar cierta cantidad de dinero para que ésta le sea devuelta. Por ejemplo: la mayoría de las empresas desarrolladoras de software en el mundo, hasta hoy sólo cuentan con sistemas de protección de sus productos para evitar la piratería usando candados en hardware, mejor conocidos como Sentinel Ultra Pro, pero po-

Para mantener la privacidad e integridad de la información, se recomienda una protección con un alto nivel de criptografía, la cual se considera como “la última línea de defensa” contra los accesos no autorizados a la información confidencial.

La criptografía proporciona a la información los siguientes elementos: •Privacidad. •Autenticidad. •Integridad. •No Repudio.

Características de una solución criptográfica Una solución de cifrado debe ser capaz de: •Proteger y ocultar la información.

Roberto González Coronel es Gerente de Desarrollo de Negocios en México y Latinoamérica para SafeNet, una empresa líder a nivel mundial en soluciones de seguridad de la información. Roberto tiene nueve años de experiencia en Seguridad Informática, y cuenta con certificaciones en diversas tecnologías de redes, comunicaciones y seguridad informática.

MAR-ABR 2007

www.softwareguru.com.mx

“Existe un amplio rango de soluciones de criptografía, que varían dependiendo de las necesidades del usuario”.

•Impedir el acceso a usuarios no autorizados a los datos almacenados en un disco duro, un dispositivo móvil o cualquier medio de almacenamiento, o datos que viajan por una red pública o privada. •Ofrecer una administración sencilla, centralizada cuando se trata de grandes ambientes y completamente transparente para el usuario. Si adicionalmente a la encripción, se desea robustecer el acceso de los usuarios a la información, se pueden usar dispositivos de autenticación de doble o triple factor para estar seguros de que la persona que está ganando acceso a la información, sea quien debe ser.

Esquemas de criptografía La solución ideal debe ser capaz de soportar los dos esquemas de criptografía más comunes: en Llave Simétrica y Llave Asimétrica. La criptografía en Llave Simétrica usa una misma llave para encriptar y decriptar la información, aquí se puede aprovechar el algoritmo AES a 256 bits, que es el más fuerte en este esquema. Un beneficio adicional de este tipo de criptografía, es que se obtiene un buen rendimiento. Pero cuando realmente el valor de la información a proteger es incalculable, debemos usar el esquema más robusto, que es el de Llave Asimétrica, mejor conocido como PKI (Infraestructura de Llave Pública). Este consiste de un par de llaves diferentes que se corresponden matemáticamente. En teoría no se puede deducir una de la otra. •La Llave Pública: se usa para encriptar datos, se comparte con los usuarios con los que se intercambia información.

www.softwareguru.com.mx

•La Llave Privada: se usa para decriptar la información, está ligada a una Llave Pública, sólo debe poseerla el propietario. Esta llave debemos guardarla preferentemente en un dispositivo de: “Autenticación de Doble o Triple Factor”, para no crear vulnerabilidad en la misma. PKI ofrece encripción de datos a longitudes de llaves de 1024, 2048 y 4096 bits, usando diferentes algoritmos.

Ejemplos de soluciones Existe un amplio rango de soluciones de criptografía, que varían dependiendo de las necesidades del usuario. Por ejemplo, hay soluciones de encripción de disco duro que colocan una barrera de protección llamada; Pre-boot, haciendo un arreglo al Master Boot Record, impidiendo el acceso total al disco cuando no se es el propietario del equipo. No se podrá ver el contenido del disco aun si éste es removido del equipo y se coloca como secundario en otra computadora. En ocasiones, únicamente se necesitará encriptar un archivo o el contenido de una carpeta compartida en un ambiente de red y no el disco duro por completo, para esto también hay soluciones disponibles.

La criptografía y las regulaciones Debido al constante robo de información, en muchos países del mundo se han creado regulaciones que obligan a empresas privadas, sobre todo del sector financiero y, a instituciones de gobierno, a encriptar la información sensible, y a su vez, castigar severamente a quién comete este tipo de delitos. Algunos ejemplos de regulaciones son: The Gramm-Leach-Bliley (Estados Unidos,

sector financiero), HIPPA Australian Federal Privacy (Australia), y European Data Protection Act (Europa). Pero, ¿por qué esperar a una imposición? ¿Si su organización maneja información sensible?, –y prácticamente cualquier organización lo hace–, entonces les recomiendo que seriamente consideren adoptar una solución de criptografía de información.

Elección de proveedores y productos En realidad, no hay muchas alternativas en el mercado que nos puedan ofrecer soluciones de cifrado con altos niveles de encripción y desempeño, por lo cual, debemos ser cautelosos para tomar la decisión correcta. Como consejo a seguir para tener la garantía de que la solución a elegir sea confiable en todos los sentidos, les recomiendo verificar que la solución que estén considerando cuente con al menos una certificación en cualquier nivel que se otorga a este tipo de productos, como FIPS, EAL o CCEAL.

Conclusión Sin duda, las tecnologías de información, la implementación de regulaciones y de políticas, y su ejecución, son elementos que permiten a los individuos, empresas y países, establecer fuertes eslabones para protegernos de ataques y disminuir riesgos de pérdidas. Una de esas tecnologías es: la integración de esquemas de criptografía, que nos dan como resultado esa “última línea de defensa” para proteger la información confidencial.

MAR-ABR 2007

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

Voodoo

Middleweight Envy a:538 Cada vez son más las empresas que ofrecen equipos personalizables, las máquinas de Voodoo (empresa recién adquirida por HP) no son la excepción, de tal manera que brindan al usuario común y al jugador, computadoras portátiles de alto rendimiento como esta. Con múltiples opciones a elegir, por ejemplo: 5 colores diferentes (bavaria blue candy, talladega black, monaco yellow, imola pearl orange y monza olive), procesadores AMD o Intel, tarjetas ATI, pantalla ancha de 15.4 pulgadas con resolución nativa de 1,900 por 1,200 pixeles y memoria RAM de hasta 2GB; por sólo mencionar algunas. Lo que Voodoo brinda es prácticamente, un pequeño taller en línea donde el entusiasta puede armar su computadora, para después adquirirla.

SanDisk

Sansa Express

Del tamaño de un paquete de goma de mascar, este pequeño reproductor MP3 basando en flash, cuenta con ranura de expansión microSD para capacidad de memoria adicional, sintonizador FM, grabadora de voz con micrófono, almacenamiento de datos y conexión directa a la computadora sin necesidad de cable USB. De tal manera que, se puede descargar música y transportar archivos de un lugar a otro. Entre algunas de sus características destacan: carga de batería sin cable, conexión USB 2.0, pantalla OLED brillante de cuatro líneas; hasta 15 horas de batería y efecto de contraluz. El Sansa Express soporta hasta 3GB de música o 750 canciones utilizando una tarjeta microSD de 2GB, que también permite transferir de forma segura a otros dispositivos compatibles, tales como teléfonos celulares o PDAs. Trabaja, a su vez, con los formatos más populares de música digital, y es compatible con Windows Vista.

Sony Micro PC UX Premium Series VGN-UX390N Más que en moda, las novedosas UMPCs (Ultra Mobile PC), se están convirtiendo en una genuina herramienta de productividad y entretenimiento gracias a la reducción de los componentes básicos y la introducción de procesadores cada vez más poderosos. Esta VAIO cuenta con un Intel Core Solo de 1.33GHz, 1GB de RAM y 32GB de memoria flash para almacenamiento. La pantalla es LCD de 4.5 pulgadas con reconocimiento de escritura, y además incorpora un par de cámaras para capturar imágenes o hacer videoconferencias. El soporte para redes incluye Wi-Fi, Ethernet y WAN para acceder a redes EDGE de telefonía —tecnología disponible en México a través de Iusacell—; los sistemas preinstalados son el Windows XP Tablet PC y el nuevo Vista. Todas estas capacidades están bien respaldadas con una batería de rápida carga y larga duración, de hasta 10 horas en uso y 20 en reposo. Un puerto USB y salidas de video y audífonos. Lo que parecía increíble hace unos años, es ahora realidad, ya que esta PC apenas supera en medidas a un Smartphone e iguala en rendimiento a una computadora de escritorio.

Logitech

diNovo Edge Este es uno de los teclados más avanzados del mundo, y al mismo tiempo, es también un complemento para cualquier computadora de alto nivel. Su diseño ultra plano ofrece además de comodidad, rendimiento gracias al TouchDisc para desplazamiento súper rápido, control con precisión de pixel que supera por mucho al tradicional touchpad. Opera con baterías de ión de litio de larga duración que se cargan a través de una base compacta, que también sirve para colocar el teclado. Cuenta con tecnología Bluetooth y está pensado en el usuario de Windows Vista, de tal manera que tiene teclas y controles retroiluminados para el acceso fácil a las principales funciones de dicho sistema operativo.

MAR-ABR 2007

www.softwareguru.com.mx

Super Talent

Ovelocking Este fabricante de módulos de memoria DDR y DDR2 y dispositivos de almacenamiento Flash para computadoras y electrónica de consumo, presentó su más reciente línea de memoria para overlocking, diseñada para brindar velocidad sobresaliente en los procesos de computo de los módulos antes mencionados y DIMM, que soportan altas frecuencias y bajas latencias. Dichos módulos están probados para cumplir con las exigentes especificaciones de las tarjetas madre más populares para entusiastas. Sus capacidades van desde 256MB hasta 1GB y cuentan con difusor de calor.

Koss

DUALphone

Cobalt Wireless Headphones

Skype 3088

Aunque la tecnología Bluetooth ha madurado y existen cientos de dispositivos que la utilizan, los audífonos existentes hasta el momento no habían logrado mantener un buen nivel de calidad de audio haciendo uso de ella. La compañía especialista en audio Koss por fin ha eliminado los problemas de descompresión de la información que plagaban los modelos disponibles y los hacían proporcionar un sonido desigual y mediocre. Los Cobalt entregan un audio claro en un rango de hasta 10 metros; se pueden conectar a cualquier equipo mediante un transmisor de miniplug o un accesorio USB, o a través de paridad con un emisor Bluetooth, sea un teléfono celular o computadora. Son recargables y su batería les da vida por un periodo de hasta 7 horas de uso continuo (el transmisor requiere baterías AAA). En cuanto a diseño, son bastante prácticos, aunque la montura detrás de la cabeza los hace un tanto incómodos para utilizarlos recostado. Se repliegan para mayor portabilidad y cuentan con un botón de ajuste de volumen y silencio.Lo mejor de estos audífonos es, sin duda, el rango que proporcionan, brindando agudos nítidos y bajos profundos, lo que los hace la mejor opción para quienes buscan disfrutar de sonido de alta calidad sin cables y desde cualquier reproductor.

Por fin, el teléfono ideal para hacer llamadas locales y sobre IP mediante el sistema Skype. Después del primer modelo, que requería conectarse a la PC mediante un cable USB y que ésta se mantuviera encendida y con la aplicación corriendo para enlazar a los usuarios, DUALphone ha dado el siguiente paso, eliminando la conexión a la computadora y agregando la posibilidad de utilizar el aparato con una línea de telefonía convencional. La base se conecta directamente a una línea telefónica terrestre y un router o switch a través de un cable Ethernet estándar. Una vez conectada la base, se puede configurar manualmente la red, u obtener una IP mediante el servidor DHCP. En la pantalla del teléfono aparece automáticamente el conocido sistema de Skype, donde, con el pad numérico se introducen los datos de la cuenta del servicio. Hasta cinco cuentas se pueden almacenar en memoria, aunque es posible hacer un login distinto para cada sesión, y cambiar manualmente entre líneas —convencional o de SkypeOut— para hacer llamadas; con el botón central del equipo se despliega la lista de contactos, para hacer llamadas directas gratuitas a los usuarios del sistema. El DUALphone 3088 es muy sencillo de instalar, usar e incluso se actualiza automáticamente; funciona perfectamente en cualquier país y su rango es de hasta 200 metros de distancia con la base. La claridad de la voz en las llamadas por Skype depende de la latencia de la conexión, pero en general es excelente.

Yamaha YSP-1100 Digital Sound Projector Para los audiófilos exigentes, nada como un buen sistema de sonido envolvente, y qué mejor que uno que incorpora todo en un solo elemento fácil de montar. El YSP-1100 se compone de 40 bocinas de rango medio que hacen las veces de canales frontales, laterales y traseros; y dos woofers para los sonidos bajos. Lo increíble de este sistema es que todos los altavoces están almacenados en un dispositivo frontal que proyecta el audio de forma direccional a la habitación, creando un efecto surround impecable sin necesidad de acomodar cada bocina. Además, incorpora un amplificador que decodifica audio en Dolby Digital, DTS, Dolby Pro Logic II y estéreo convencional. Su control remoto de sencilla interfaz facilita la programación de canales, y su sistema de calibración automatizada Intellibeam, permite que cualquier usuario lo configure en unos cuantos minutos sin importar el tipo y las dimensiones de la habitación en que se instale. www.softwareguru.com.mx

MAR-ABR 2007

// COLUMNA

/*TIERRA LIBRE*/

Desarrollando Nuevos Talentos con Software Libre Es Momento de Bajarse de la Nube

Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org

l imaginar los talentos del software libre en México, podemos pensar en una serie de vacas sagradas que tuvieron la fortuna de ser contemporáneos del “oh, todopoderoso” Miguel de Icaza, estrella más grande del movimiento en nuestro país. También podemos pensar en aquellos que organizan tantos congresos anuales de software libre por separado, en lugar de trabajar en equipo para realizar un solo evento de mayores dimensiones y alcance. No, para mí, el verdadero talento del software libre en nuestro país no está ahí. Son mucho más jóvenes, tanto, que ni siquiera están en las universidades, están en las preparatorias. Esto permite que su principal interés todavía sea aprender, y no el tener una “carrera”. Esta visión difiere de aquella en la que han caído muchos de nuestros universitarios, que tan solo ven la tecnología como la manera mas rápida de llegar a ser dueños de su propia empresa evasora de impuestos. En cambio, estos jóvenes aún no quieren saber lo que valen. Simplemente desean una oportunidad de aplicar su talento y pasión por el software, en proyectos interesantes, que tengan algún beneficio social, sin más paga que la satisfacción de saber que están contribuyendo a cambiar el mundo. Sé que al leer estas líneas, probablemente pensarán que esto es imposible en nuestro país. Lo mismo afirmaba el director de una organización sin fines de lucro, cuando le sugerí apoyarse en un programa de voluntarios que le desarrollara su sitio web. Su respuesta fue: “por favor, estamos en México, aquí no existen voluntarios...”. Vivimos en el México que somos capaces de ver y de imaginar. Me considero muy afortunado de haber conocido hace ya un par de años a dos grupos que muestran claramente lo que pueden hacer los jóvenes. El primero son tres chavos: Luis, Julio y Vicente, conocidos como LEIS (Laboratorio Experimental de Informática Social). Dicho proyecto fue creado por Jesús Polito Olvera, director de la carrera de Técnico Programador en la vocacional No. 9 del Poli (la famosa “Juan de Dios Batiz”). Su propósito era ver qué pasaba cuando los estudiantes de programación más talentosos eran expuestos a las necesidades del sector no lucrativo. El proyecto inicial ya terminó, y los resultados excedieron por mucho las expectativas. El LEIS continua activo. No tienen oficinas, no tienen financiamiento, pero sí tienen una buena red de contactos que constantemente los expone a proyectos donde pueden cada día aprender más, resolviéndole problemas a terceros; que nosotros, los “ilustres” profesionales de la informática, ignoramos, porque no hay dinero involucrado, y porque estamos muy ocupados peleándonos por los 20 proyectos corporativos más grandes del país. El otro grupo, aún más sui-generis, es Icenet-X. Este es un grupo de jóvenes “ex-hackers”, todos de menos de 20 años. Gaper, Brio y Ayzax, tres de sus principales miembros, son ya muy conocidos en el

MAR-ABR 2007

circuito universitario. Se han dado a la tarea de llegar a los muy jóvenes como ellos, y hacerles ver que, usar software libre es mucho más que una forma de no pagar licencias a la empresa de las ventanas, sino que es una completa filosofía de vida, que puede lograr que cada quien sea independiente y autosustentable. Tanto Icenet-X como LEIS, tienen sus particularidades. Sin embargo, ambos han elegido bajar el movimiento del software libre de los cielos de las vacas sagradas, a nuestras secundarias. Así que la pregunta es, ¿qué estamos haciendo nosotros, los experimentados, por ayudar a las nuevas generaciones? Es aquí donde creo que podemos hacer algo dentro de nuestras organizaciones. La propuesta es muy sencilla: abandonemos el degradante modelo de los “becarios” para introducir a nuevas personas a nuestras empresas, y en su lugar iniciemos proyectos de tecnología social, como una forma más efectiva de reclutamiento. Es decir, realicemos proyectos de tecnología aplicada a beneficio social, involucrando a jóvenes voluntarios para la ejecución de dichos proyectos. La propuesta que he visto funcionando en varios lugares, requiere de los prerequisitos: •Compromiso social de la organización: debemos entender que somos la elite informática de este país. Estamos muy por encima de la enorme brecha digital que cada vez se ensancha más en nuestro país. Tenemos una responsabilidad con México, de hacer lo que podamos para ayudar con lo que mejor sabemos hacer. Como dice la trillada frase: “con gran poder, viene gran responsabilidad”. •Compromiso con los voluntarios: ¿si el dinero no es lo que buscan, entonces qué buscan estos jóvenes? La respuesta es sencilla: experiencia y un muy buen ejemplo. Compartamos con ellos nuestra experiencia y démosles un ejemplo de cómo ser excelentes profesionistas, lideres y personas. Esta es nuestra verdadera oportunidad de sembrar semillas de la mejor calidad para nuestra industria. •Liderazgo efectivo: todo proyecto requiere de un buen liderazgo, y el mejor liderazgo es el que enseña a ser proactivo y autodirigido. En estos proyectos tenemos un entorno muy diferente al de nuestros clientes, y podemos aplicar todas esas prácticas innovadoras sobre las que hemos leído, pero no hemos podido aplicar. Quién sabe, a lo mejor hasta nuestros proyectos comerciales se benefician de lo que aprendamos. Los invito a que se den oportunidad de probar este sencillo modelo de detectar y apoyar nuevos talentos. Los jóvenes, la industria, y el país lo necesitan. — Emilio Osorio www.softwareguru.com.mx

INDEX

DIRECTORIO

Anunciante

Pรกginas

Sitio

AMCIS Avantare e-Quallity Intersoftware IDC Itera Microsoft Milestone Consulting Roca Sistemas SafeNet Softtek Sun Tech Days

55 45 47 F2 F3 17 13 F4 01 07 43 11

www.amcis.org.mx www.avantare.com www.e-quallity.net www.intersoftware.com.mx www.idc-eventos.com www.itera.com.mx www.microsoft.com/mexico www.milestone.com.mx www.rocasistemas.com.mx www.safenet-inc.com www.softtek.com www.suntechdays.com.mx

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

www.softwareguru.com.mx

MAR-ABR 2007

// REFLEXIONES

El Nacimiento de una Estrella La Industria Mexicana del Software Por Leonardo N’Haux

Acompáñenme al pasado, por favor ... México, a principios de la década de los noventa. ¿Se le habrá ocurrido a alguien en este entonces, que México podría ser el principal proveedor de servicios de software de Estados Unidos? En realidad no podemos saberlo, sólo podemos especular que : a) A nadie se le ocurrió. b) A alguien se le ocurrió y no lo dijo. c) Lo dijo, pero nadie le prestó atención. India: misma época, misma pregunta. En este caso la respuesta es un contundente, “Sí”. A alguien se le ocurrió, lo comunicó efectivamente, y se puso en marcha un plan integral, donde todos hicieron lo que tenían que hacer para ser hoy potencia mundial en la industria del software. Ahora volvamos al presente. El Gobierno Federal, junto con algunos estados que, aunque tarde, entendieron antes las tendencias mundiales, definieron su mensaje hace unos pocos años atrás: “El primer paso es fortalecer las capacidades de las empresas”, esto incluía integración de las empresas, formación de recursos humanos, certificación a nivel personal y a nivel empresas.

15. Teniendo en cuenta la cantidad de empresas que están en proceso, y su nivel actual de avance, no es aventurado pensar que a finales del 2007 ese número rondará la cantidad de 35. Si PROSOFT persiste en su estrategia, y sus planes tienen continuidad en el futuro, esa proyección aumentará significativamente año con año. Repasando las cifras, es evidente que pasar de 3 a 35 en tan solo dos años es un dato llamativo. Tan llamativo, que está captando la atención de grandes compradores del vecino país del norte, cuyo trabajo es precisamente estar en la búsqueda constante de mejores, más rentables, y eficientes proveedores de outsourcing para resolver sus necesidades. Estamos siendo testigos del nacimiento de una industria que en corto plazo representará una porción significativa del PIB mexicano. Esto no se dará tan solo por el apoyo gubernamental al sector, o por las inexistentes estrategias de exportación de las PyMEs locales, sino más que nada, por la decisión de nuestro todopoderoso vecino del norte, quién ya ve la posibilidad de tener a la vuelta de la esquina, un proveedor al que pueda ir a visitar en la mañana, y poder estar de regreso en su casa para darles el beso de las buenas noches a sus hijos, antes de dormir.

Podrá haber quienes estén a favor o en contra de esta aseveración, pero lo que nadie puede discutir, es que era una necesidad real, que requería de urgente atención y solución. Se definieron planes, se unieron Estados con iniciativa privada, bajo el paraguas del Programa para el Desarrollo de la Industria de Software (PROSOFT), y hoy, los resultados muestran a dicho programa como uno de los más exitosos del sexenio anterior.

Esto no es futurismo, esto está sucediendo. India ya tomó conciencia, y está tomando acción al respecto, basta con mencionar que Wipro, Infosys y Tata, tres de las principales corporaciones de las tierras del legendario Ghandi, ya han enviado a sus directivos a elegir locaciones para instalar sucursales de sus fábricas en México.

Si tomamos como indicador la cantidad de empresas acreditadas CMMI. Al comenzar el 2006 solo había 3 empresas con acreditación CMMI en México. En cambio, un año después, son casi

No tengan dudas, muchas empresas llegarán, muchas nuevas nacerán, algunas actuales desaparecerán, pero a lo largo del proceso, la industria como tal se verá fortalecida.

Leonard N’Haux es Director General de Innevo, una empresa mexicana con sede en Guadalajara y oficinas en Monterrey y DF. Innevo cuenta con dos unidades de negocio: Calidad de Software y Desarrollo de Software, esta última acreditada CMMI L2, y en proceso de acreditarse CMMI L3. Innevo es líder en México en proyectos asociativos, colaborando con los clústers de software de Nuevo León, Coahuila, Sinaloa, Guanajuato, DF, Baja California y Morelos.

MAR-ABR 2007

www.softwareguru.com.mx

Aﾃｱo 03 No. 02

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Marzo-Abril 2007