SG14 (Marzo-Abril 2007)

Software Guru CONOCIMIENTO EN PRÁCTICA

www

.sof

twar

egur

u.co

m.m

x

Año 03 No.02 • Marzo-Abril 2007 • www.softwareguru.com.mx

[ Fundamentos ]Ingeniería Web

Noticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

• AnálisisdePuntosdeFunción

• EvaluacióndeArquitecturas

• ModelDrivenDevelopment

Equípate[ENTREVISTA]MarianaPérez-VargasAbriendobrecha

ESPECIALUnvistazoa

laindustriadesoftware

México, $65.00

HerramientasdeDesarrollo

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

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

ColaboradoresJorge 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

FotografíaGabriel González

Ventas Claudia Perea

Natalia Sánchez

Marketing y RPDafne Vidal

Circulación y Subscripciones Daniel Velázquez

[email protected]

+52 55 5239 5502

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: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en febrero de 2007 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.

directorio

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 ci-clo 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 coman-dos, pero sabemos que eso ya es más un arte que una profesión. Las característi-cas 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 encon-tramos muchas organizaciones que pre-fieren meter más gente, o tardarse más,

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 herramien-tas, ya que existen muchas opciones gra-tuitas 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 informa-ción les sea de beneficio y los ayude a crear mejor software. Agradeceremos sus comen-tarios, sugerencias y propuestas de partici-pación en [email protected]

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.

Editorial

// CONTENIDO

02 MAR-ABR 2007 www.softwareguru.com.mx

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

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

Tendencias en Software 46por Luis Daniel Soto

Tierra Libre 54por Emilio Osorio

Un vistazo a la industria mundial de software

14

EntrevistaMariana Pérez-Vargas

18En Cada Número

NOTiCiAS y EVENTOS 04CLÚSTERS 06UML 44FUNDAMENTOS 48iNFRAESTRUCTURA 50REFLEXiONES 56

Productos

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

Prácticas

ADMiNiSTRACiÓN DE PROyECTOS 34Aná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 36Evaluando la Arquitectura de SoftwareEn esta segunda parte, Omar Gómez nos explica cuatro métodos de evaluación de arquitecturas.

ESTRATEGiAS DE DESARROLLO 40Desarrollo Dirigido por ModelosSergio Cedillo comparte con nosotros este artí-culo donde se analizan las actividades requeri-das durante un proyecto de MDD.

EN PORTADA

Herramientas de softwareEstudiamos cómo es que las herra-mientas modernas asisten el ciclo de desarrollo de software.

20contenido mar-abr 2007

03MAR-ABR 2007www.softwareguru.com.mx

// CONTENIDO

CONSOL 2007Del 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 soft-ware, 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 Digi-tal de Restricciones, entre otros especialistas. Con este evento México de-staca 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

SolidWorks World 2007Del 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

// NOTICIAS

PROSOFT publica reglas para 2007Para el 2007 PROSOFT tendrá una aportación de 462 millones de pesos, 8 por ciento más que en 2006, estimando detonar inversiones estat-ales y de iniciativa privada por unos 1,380 millones de pesos. Entre sus objetivos están: apoyar 350 proyectos empresariales, generar 8 mil em-pleos, 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


Tecnológico de Monterrey y NIITfirman convenioEl 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 compro-miso que el Tecnológico de Monterrey tiene con el desarrollo de las tecnologías de información en México.

// EVENTOS


8 Marzo 2007SAP Technology Day ‘07Centro Banamex, Cd. de MéxicoInfo: www.sap.com/mexico/techdayy07 Tel: (55) 52651601

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

12 al 16 Marzo 20071ra. Semana de Sistemas y ComputaciónTecnológico Superior de Huetamo, MichoacánTel: (435) 556 2774Email: [email protected]

22 al 24 Marzo 2007III Simposio Metodología Seis SigmaCentro de Investigación en Matemáticas (CIMAT)Hotel Real de Minas, Guanajuato, Gto.Info: www.cimat.mx/sitios/seissigmaEmail: [email protected]

19 al 20 Abril 2007Gartner Enterprise Integration SummitCentro Banamex, Cd. de MéxicoInfo: www.gartner.com/mx/appintTel: (55) 5584 9370Email: [email protected]

25 y 26 Abril 2007IDC Web Security Conference 2007Centro Banamex, Cd. de MéxicoInfo: www.idc-eventos.comTel: (55) 5604 2663Email: [email protected]

Zacatecas obtiene certificaciones PSP

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 capacita-ció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 pro-ceso de desarrollo de la industria de TI’s en el estado, al que le seguirá la adecuación de los programas educativos universi-tarios 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.

Cega Software obtiene Norma MexicanaEl 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


ConclusiónInteQsoft 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 condi-ciones 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

/* CLUSTERS */ // INDUSTRIA

IntegrantesJorge 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 Uni-versidad 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 Tele-com, Praxis, Kepler, Opalo Software, AxS Tracker, Resource IT y FASST.

Las dos grandes áreas de especialidad en este cluster son desar-rollo 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ónUno 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 em-pleos 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 Inves-tigació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.

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

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

ServiciosEntre los servicios que inteQsoft ofrece a sus clientes y asocia-dos 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 ResultadosinteQsoft se ha consolidado con una inversión de 47.4 millones de pesos. Se han desarrollado 18 proyectos, con más de 49 em-presas 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 ac-tualmente hay 8 empresas certificadas o acreditadas en algún nivel de un modelo de procesos como CMMI o MoProsoft, y otras 11 en pro-ceso de certificación.

inteQsoftMente de obra para una mayor calidad de vidaQueré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.


Hace un año nació el proyecto COMPETISOFT, apoyado por el orga-nismo Iberoamericano CYTED (Ciencia y Tecnología para el Desarro-

llo). “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 necesida-des 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, pre-sentada en la figura 1 (siguiente página), supone como puntos de partida los modelos y trabajos ya existentes, en particular: MoPro-Soft 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 Es-pañ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 retroali-mentar al WG24, con los experimentos en varios países. Aprovechamos la presencia de personas relacionadas con organismos de normaliza-ció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 he-rramientas. 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 lla-mamos: 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”;

COMPETiSOFTColaborar 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, Tecnolo-gí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.

// COLUMNA /*TEJIENDO NUESTRA RED*/// COLUMNA

Figura 1. Visión general del proyecto COMPETISOFT

/*TEJIENDO NUESTRA RED*/

total que acabamos acordando la necesidad de crear un glosario mul-ti-español-castellano, para tener las versiones de los modelos que sean entendibles en cada país. Para acabar con este pequeño pleito, decidi-mos 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 ma-nera sincera, le interesa apoyar a la gente de América Latina. Es un “pro-ductor” 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, Guate-mala, 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

Hace ya más de dos años inició esta aven-tura 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 gus-taría que nos preguntemos ¿Donde nos en-contramos? ¿Hemos mejorado la forma en que desarrollamos software? ¿Hemos avan-zado con nuestros planes de mejora conti-nua? ¿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éxi-co ha crecido como lo ha hecho en estos últi-mos 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? De-finitivamente, 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 mode-los más famosos de calidad se conoce como el Ciclo Deaming.

El Ciclo Deaming nos dice que toda estrate-gia de calidad inicia con una etapa de pla-neació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.

Planeación1. Definir un objetivo claro, que indique a donde queremos llegar. En mi expe-riencia, la principal causa de fracasos en esfuerzos de calidad, es que el obje-tivo sea demasiado amplio o demasiado vago; “Queremos ser la organización de mayor calidad en todo el mundo”, sue-na muy interesante, pero no es lo más apropiado para iniciar un proyecto. El-ementos más específicos como “Vamos a estandarizar la forma que estimamos para obtener datos comparables” o “Va-mos 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 prob-lema 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 di-ciendo quien va a ayudar, no quien debe de participar. Tiene que ser gente con influen-cia, 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 ac-tividades que no van a verse hasta dentro de mucho tiempo.

Do, Check, Act ¡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) Repar-tir 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 re-spuesta 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 eje-cutará el plan. Adicionalmente, aquí es donde paga haber escogido las actividades de mayor impacto. Entre más visible es el avance más mo-tivació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 cali-dad y mejora continua no son metas, sino caminos a seguir. RecapitulemosYa 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 di-recció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 ilumi-nar el camino. Las cosas que valen la pena se dan paso a paso. ¡Bien pues, iniciemos!

—Luis Cuellar

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

/*MEJORA CONTINUA*/// COLUMNA

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.


Figura 1. Ciclo Deaming

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 herra-mientas que soportan la implantación y monitoreo de procesos de aseguramiento de la calidad.

Compuware Quality Management asiste a las organizaciones a im-plantar 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.

Mayor información en www.compuware.com

XQuery 1.0 y XSLT 2.0Estándares XML aprobados por el W3C

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 relaciona-les, y los documentos. Entre las principales especificaciones que se hicieron oficiales están XQuery 1.0, XSLT 2.0, y XPath 2.0.

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

Parasoft SOATestPorque SOA también requiere ser probado

Parasoft liberó SOATest 5.0, una herramienta espe-cíficamente diseñada para probar y asegurar la cali-dad, seguridad y confiabilidad de las aplicaciones orientadas a servicios. Una de las características principales de SOATest es su habilidad de anali-zar 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 apli-caciones 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 indepen-dientes, sino también a nivel de mensajes, que se deben probar en tiempo de ejecución en un ambiente distribuido simulado.Parasoft se ha en-focado en proveer una herramienta que resuelva esta problemática, y al parecer lo ha hecho exi-tosamente con SOATest 5.0.

Mayor información en www.prosoft.com

PHP 6Finalmente orientado a objetos

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 ver-sió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 estabi-lidad, seguridad y “mantenibilidad”.

Es así que uno de los temas centrales en PHP 6 es la orien-tació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 obsole-tas de freetype y GD1.

Mayor información en www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html

/* LO QUE VIENE*/// PRODUCTOS


Sin lugar a dudas, en la última década, el desarrollo de las tecno-logías de la información ha llegado a impactar en forma directa o indirecta a prácticamente todas las actividades económicas y al que-hacer cotidiano del ser humano. En el caso de la Industria del Soft-ware, la demanda de productos y servicios derivados de ésta tiene una de las tasas de crecimiento mundiales más altas de la actuali-dad, 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 denomina-do: 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 clasi-ficación de mercado del software y sus cifras globales, así como su vinculación con el concepto de ecosistema empresarial.

Ecosistema EmpresarialEl concepto de ecosistema empresarial (business ecosystem), es un concepto de planificación estratégica que surgió bajo este nom-bre 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.

En términos generales, se puede decir que un ecosistema em-presarial 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á condicio-nada 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 pro-ceso 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 de-finiciones más representativas del concepto ecosistema em-presarial. 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


Un Vistazo a la industria M

undi

al d

el S

oftw

are

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

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 di-námica, que está compuesta por empresas que están interconecta-das, 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, or-ganizaciones del sector público y otros grupos. Por tanto, es esta diversidad, aunada a la complejidad del mercado de software, don-de 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 com-plejidad 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 entregaEsta clasificación determina que el software puede ser empaqueta-do o hecho a medida. Esto tiene como consecuencia las diferentes formulaciones y alcances en la forma de comercializar, cobrar, es-tructurar los canales de distribución, los servicios de soporte, actua-lizaciones, entre otros temas.

a) Software empaquetado: un producto de software empaque-tado 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ódi-go 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ó-

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 finPara un mejor entendimiento de esta clasificación, hay que consi-derar 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 soft-ware al negocio. La clasificación vertical establece una sub- clasifi-cación para el software de aplicaciones empresariales.

El software de aplicaciones empresariales: es un producto em-paquetado, 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 hori-zontal y el vertical.

•El segmento horizontal, agrupa a todo software de aplicación em-presarial 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 ma-yor crecimiento en el planeta. Según cifras de IDC durante 2003, ésta generó alrededor de 1,400,000 millones de dólares. La in-dustria 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 indus-tria 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 concen-tran 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


Un Vistazo a la industria

Mun

dial

del

Sof

twar

e

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 tie-ne Estados Unidos con un 40%, seguido de Japón con un 10%.

El software operativo de sistemas, que es el que controla el funcio-namiento 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 modali-dades 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 norteameri-canas 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 em-pleada 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 plan-teado 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 Indus-tria 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 exis-ten 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 satis-facer 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 inclu-ye 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].

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 platafor-mas comunes y aplicaciones middleware para muchos usuarios, 6% en capacitación y 4% en otras iniciativas. Las empresas en-tre 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 infra-estructura 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 ma-yor 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).


2003 2004 2005 2006 2007

2.0% 3.4% 4.2% 5.8% 6.8%

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 Organiza-ció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: [email protected] [email protected] consultoría en mejora de procesos.

Tabla 1. Proyecciones de la tasa de crecimiento de la industria del software a nivel

mundial [9].


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

Referencias Bibliográfica1. 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/20064. 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). Ins-titute 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-Di-ciembre, 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 & In-formation Industry Association.10. Sandhill (2006b). CIO Insight Survey. Proceedings 2006. En: SandHill.com (Ed.), Conference: Software 2006, Unifying the Ecosystem, Santa Clara, CA.

ConclusionesEl desarrollo del software es complejo por naturaleza, el alcance e impacto de sus apli-caciones 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 con-formació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 lo-grar 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 compe-tidores 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.


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


Cuéntanos un poco sobre tu trayectoria.Soy Licenciada en Informática de la UNAM. Al salir de la escuela tra-bajé tres años en Banamex, y después de eso me incorporé a Tec-nosys, 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.

¿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 pro-cesos, para mejorar tu calidad”, y la respuesta que nos encontrába-mos era: “¿Procesos? No, para qué, así estamos bien”.

¿Qué hizo que cambiaran las cosas?Cuando Tecnosys se certificó, otras empresas competidoras comen-zaron 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 interesa-dos, 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 proyec-tos 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 em-presas sólo busquen el papelito de certificación, sin preocuparse realmente por mejorar. Es una situación complicada, porque yo en-tiendo 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 resulta-do 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 desarrolla-doras 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 MoPro-Soft es: “si lo que yo quiero es vender servicios a Estados Unidos, y

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 ob-jetivos y necesidades de cada organización. Esta es una de las áreas donde un consultor de procesos puede agregar valor.

¿Qué sugieres que se haga para dar mayor difusión y credibili-dad a MoProSoft?Yo creo que se necesita a algún organismo que sea el dueño de Mo-ProSoft. La industria no puede ser el dueño, porque hay intereses particulares. La academia tampoco puede ser, porque no está sufi-cientemente 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 desa-rrollo y difusión de MoProSoft, que sea el que acredite a los evalua-dores, y a los proveedores de servicios. Esto sería de gran beneficio para todos.

¿Cuál es la percepción en México de los consultores?En general a las organizaciones en México no les gustan los consul-tores, 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 provo-cado 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 mis-mo camino. ¿Qué significa esto para México?Va a ayudar a reducir los costos de las evaluaciones, ya que va a ha-ber mayor disponibilidad de personas que puedan hacer evaluacio-nes 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 pe-queñ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 fundamen-tal. Tienes un campo enorme de trabajo, porque en todos lados se necesita software. Además, no sólo está la parte de programa-ció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, por-que a fin de cuentas lo que se hace es crear sistemas que auto-maticen 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úten-la. Por otro lado, que trabajen con calidad, y que siempre busquen mejorar. Mejorar empieza desde uno como persona, y debe ser por-que uno está convencido, no porque lo obligan.

// ENTREVISTA

Cualquier profesión requiere de herramientas; y el desarrollo de soft-ware 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, fun-cionalidad, 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 faci-litarla. 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 ilus-trar 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 pro-veedores, y cuál brinda la solución más adecuada a las necesidades de su organización. Dicho lo anterior, comencemos ...


El objetivo principal de este artículo es pre-sentar un panorama sobre las herramientas

de software libre u open source, relacionadas con la generación de un ambiente de desarro-llo integral, que cubra las diferentes etapas in-volucradas en la creación de software.

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 pro-yectos open source, sino que se pueden utili-zar para cualquier tipo de proyecto.

Un vistazo a las diferentes necesidadesDesde un punto de vista muy simplista y, sin estar apegado a alguna metodología especí-fica, podemos identificar las siguientes eta-pas en el ciclo de vida de un proyecto:•Planeación y costeo.

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

¿Cómo seleccionar las mejores herramientas para cada una de estas etapas? Las revisiones de producto son útiles, pero no son la última pa-labra, 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; ta-maño de proyectos y equipos de trabajo.

A pesar de estas limitantes para la selección de herramientas, lo que está claro, es que debemos seleccionar aquéllas que nos ayu-den 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.


Open Sourceal Rescate

Por Francisco Castrillo


Herramientas de colaboraciónComencemos por mencionar algunas he-rramientas orientadas a coordinar y facili-tar la colaboración entre los miembros de un equipo de trabajo. Aquí tenemos las si-guientes categorías:

Control de versionesEl 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 docu-mentació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, do-cumentació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 Subver-sion; 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. En-tre 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 multiplatafor-ma para acceder a los repositorios.

Entre las principales diferencias a nivel conceptual (no de implementación), está el reemplazo de etiquetas (tags) y ramas (bran-ches) de CVS por simple copiado y renombra-do de archivos y directorios en Subversion.

issue trackingUtilizado para manejar las listas de pendien-tes a resolver y las solicitudes de mejora. Es indispensable contar con visibilidad de los asuntos por resolver, así como un mecanis-mo automatizado de asignación de tareas y notificación de alertas. Toda esta funciona-lidad la provee una herramienta como Bug-zilla, la cual fue originalmente desarrollada para atender las necesidades del proyecto Mozilla, y ahora se ha convertido en la he-rramienta por excelencia para manejo de issues. Los usos que se le pueden dar a la herramienta son muy variados: los desarro-

lladores pueden rastrear defectos o bugs; los usuarios solicitan soporte, asignación de tareas de codificación y/o corrección, con-trol de actualizaciones o parches y discusión sobre posibles mejoras.

Discusiones técnicasEn este rubro se pueden utilizar una diver-sidad de mecanismos que promuevan el en-tendimiento 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 posibi-lidades 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 Mail-Man, que ofrece una interfaz web para utilizar listas de correo electrónico, diver-sas 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 ar-chivos y crear páginas (tipo Wiki) desde la misma interfaz web.

Herramientas de desarrolloEn cuanto a las herramientas de desa-rrollo 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 cons-trucción o implementación.

Editores de textoSi consideramos que las herramientas son una extensión de nuestras manos, esto apli-ca mejor que en ningún otro caso para los editores de texto. Lo ideal es conocer un editor lo mejor posible y utilizarlo para cual-quier tarea de edición: código, documenta-ción, scripts, notas, entre otras.

Las características esenciales que debe te-ner 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 popula-res 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 extrema-damente útiles.•Funcionalidad robusta y de gran diversidad: búsquedas, ejecución de comandos, ftp, so-porte para múltiples buffers, highlighting, indentación automática; soporta diversos modos de edición, juegos, calendario, con-trol 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 familiari-zados con Unix, Ant es el equivalente al co-mando “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, desplie-gue 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-

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.


zado. Maven agrupa las “mejores prácticas” y asume cierta estructura de directorios con el fin de estandarizar tareas. Adicional-mente, 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 in-fraestructura de muchas plantillas de pro-yectos 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 cuen-ten 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 in-tegran 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 servido-res de aplicaciones, refactoring) que no cu-brimos en este artículo.

La tarea de elegir un IDE es verdadera-mente difícil. Cada una de las opciones presenta ventajas y desventajas. Sin em-bargo, podemos tomar en cuenta algunas consideraciones al momento de hacer esta elección: •Naturaleza del proyecto a realizar. Es im-portante considerar las características del proyecto a desarrollar para así, poder delimi-tar 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 desa-rrollo requieren de una capacidad mínima para que funcionen de manera óptima.•Flexibilidad de la herramienta. Existen he-rramientas 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 de-teriorar 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 so-bre el funcionamiento del IDE. •Perfil del desarrollador. Algunas caracte-rí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 op-ciones como alternativas open source: Eclipse y NetBeans. En cuanto a la filosofía que promueven con su arquitectura, am-bos fueron implementados alrededor de un pequeño núcleo con todas sus carac-terísticas implementadas como plug-ins. Ambos sirven como plataforma base para otras herramientas de valor agregado que proveen las empresas que fundaron a es-tos 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á diri-gida 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 Eclip-se, existen diversos productos de IBM construidos sobre esa plataforma, es-pecialmente 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 oca-siones es mejor utilizar sólo un buen editor

de texto. De cualquier forma, no olvidemos que las herramientas de programación de-ben 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 cum-plir con estos objetivo.

ConclusiónIndependientemente de la selección de herramientas para generar nuestro en-torno de desarrollo colaborativo, con-viene tener muy presente dos cosas:1. Las herramientas de colaboración no son un sustituto de la comunica-ción directa con los otros miembros del equipo de trabajo, también es importante establecer las “reglas de uso” de las herramientas para facili-tar su adopción2. En cuanto a las herramientas de de-sarrollo, 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


Este 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 activida-des, 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.

Las dos áreas de mayor oportunidad¿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

están a unas horas del compromiso de libe-rar un sistema a producción?

Estos escenarios ejemplifican los dos subpro-cesos 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 enfo-carse primeramente en agilizar la definición y ejecución de casos de prueba.

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 im-plementación de pruebas automatizadas.Y es que es humanamente imposible, rea-

lizar todas las pruebas requeridas para que un sistema tenga una calidad acepta-ble, 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 imple-mentar esto recomiendo aplicar el concepto del marco de ejecución de pruebas.

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 ágilesMediante automatización efectivaPor Ariel Sucari


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

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 ingenie-ros de pruebas, para luego volcarlos a la aplicación.

El marco de pruebas automatizado debe ser capaz de analizar, si luego de introducir to-dos los datos leídos, el resultado que mues-tra 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 ejecu-tarse, 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 fuen-te de datos de entrada dinámica. La figura 1 ilustra a grandes rasgos el funcionamiento de esta técnica.

Figura 1. Marco de pruebas automatizadas

Con esto se logran dos cosas muy impor-tantes que contribuyen a mitigar los ries-gos antes mencionados.1. Los analistas del sistema generan una par-te 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.

Factores críticos de éxito El error más común es, leer un artículo de es-tas características y lanzarse a comprar una herramienta de automatización de pruebas, y entregárselas al equipo esperando los resulta-dos aquí descritos. El hacerlo, no sólo lleva a la frustración personal de cada uno de los involu-crados en el proyecto, sino al escepticismo por parte de la organización, hacia la automatiza-ción de pruebas. Para resolverlo, deben tener-se en cuenta una serie de puntos:

La curva de la “JOTA”. Es muy frustrante comenzar un proyecto pensando en que pa-saremos de A a C sin pasar por B. Toda in-novació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 prue-bas, muchas organizaciones abandonan los esfuerzos de implementación cuando se en-cuentran en el punto B, por desconocimiento de la curva de aprendizaje. Es de suma im-portancia, antes de comenzar el proyecto, diseñar la curva y estipular los tiempos pre-vistos para transitar desde A hacia C deta-llando expresamente el punto B.

Contar con personal con experiencia en desa-rrollo. 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, preferente-mente 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 des-cartarán las pruebas manuales. Muchas organizaciones piensan que luego de la fina-lizació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 con-veniente que en una etapa inicial del desarro-llo, se efectúen manualmente.

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.

ConclusiónEl marco de automatización de prue-bas 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 es-tán familiarizadas con esta técnica.

Me he preguntado el por qué de este hecho, y no he dado con una respues-ta certera. Tal vez se deba a que las he-rramientas en la antigüedad no eran lo suficientemente flexibles como para que los programadores se sintieran có-modos, y se animaran a crear un mar-co 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 ge-nerar conciencia en las organizaciones del valor real de esta práctica.

Figura 2. La curva jota

Hasta hace pocos años, un desarrollador de software que quisiera utilizar herra-

mientas 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 esce-nario 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 us-tedes saben, esto tiene dos grandes inconve-nientes: 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 en-tre herramientas. La novedad aquí no es que

dos herramientas diferentes se puedan comu-nicar, sino que dentro de una herramienta se pueda “embeber” a otras, a través de plug-ins y perspectivas. Así, el desarrollador sólo re-quiere abrir su IDE, y desde ahí tiene toda la funcionalidad que requiere. Aunque este pa-radigma 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 es-tán dejando de ofrecer ediciones independien-tes de sus productos, y en su lugar, los ofrecen como plug-ins para Visual Studio y/o Eclipse.

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

tomar como referencia a Visual Studio Team System, y haré un ejercicio de cómo se inte-gra con diferentes herramientas para resol-ver 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 desarro-llo de software empresarial. Team System se distingue del Visual Studio normal (o “a secas”), en cuanto a que ofrece un con-junto 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 ver-siones 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


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 ren-table y que genere software de calidad.

Integración de HerramientasUn Nuevo Paradigma para el Desarrollo EmpresarialPor Marcos del Pozo

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

Gestión de requerimientosPara consolidar el proceso, y tener una he-rramienta sólida para la definición de reque-rimientos que se complemente fácilmente, podemos integrar una herramienta de Bor-land 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 nego-cio, analistas, desarrolladores, probadores, arquitectos y otros interesados. CaliberRM provee la funcionalidad requerida por el rol de “analista de requerimientos”, ofrecien-do así a los equipos de desarrollo, la ca-pacidad 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 usua-rios, la capacidad de colaborar para capturar los detalles de escenarios posibles y validar-los a través de la creación de guiones visua-les. Es así como, con la integración de las herramientas de Borland, podemos asegurar la entrega del software alineada a la deman-da de los usuarios y cumplir con los requeri-mientos del negocio.

Diseño y arquitecturaEnterprise Architect es una excelente he-rramienta 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 ha-cer generación de código a partir de mode-

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

Gestión de pruebasLa empresa AutomatedQA, cuenta con una herramienta llamada TestComplete, que tiene una completa integración con la edi-ción Tester de VSTS. TestComplete ofrece un ambiente de pruebas sistemático, automa-tizado, y estructurado para desarrollos en lenguajes como .NET, Java, Visual C++, Vi-sual Basic, WPF (XAML), Delphi, C++Builder y aplicaciones web. Además con TestComplete se pueden probar aplicaciones de Power-Builder, FoxPro y Access.

Soporte a entornos heterogéneosHemos comentado sobre la colaboración de propuestas que impactan en el ciclo de vida del desarrollo. Sin embargo, nos debe-mos 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ísti-cas de Team Foundation Server a entornos heterogéneos. Con Teamprise, los adminis-tradores, desarrolladores y probadores tra-bajando con distintos sistemas operativos, pueden acceder a TFS. Por ejemplo: un de-sarrollador de Java trabajando desde Eclip-se en Linux, podría utilizar TFS para toda la colaboración y seguimiento al proyecto. Esto permite que las organizaciones inte-gren herramientas sin necesidad de modi-ficar su infraestructura.

Acceso universalPor último, quiero hacer mención a una he-rramienta Teamplain, de la empresa DevBiz Business Solutions. Esta es una herramien-ta que a través del web nos permite admi-nistrar 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 he-rramienta sencilla de utilizar.

www.softwareguru.com.mx 27MAR-ABR 2007

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.

ConclusiónLa experiencia nos confirma que, el desarrollo de software es un proce-so difícil. Entregar un producto de calidad y que cumpla con las ex-pectativas 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 herra-mientas, sino al contrario, podemos integrarlas de acuerdo a nuestras necesidades en busca de la consoli-dación del proceso de desarrollo de software, que poco a poco se vaya acercando a cumplir con la genera-ción de un software de calidad y un cliente satisfecho.

Referencias a lasherramientas 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

Esta 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 in-formació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 encon-trar información y, a partir de ésta, generar mayor conocimiento. El concepto de comuni-cació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 retroalimen-tación de distintas ideas, pensamientos, e incluso innovación. Esta forma de relacionar-se, 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 ni-veles incluso profesionales y de negocios.

Las herramientas y soluciones de produc-tividad 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 empre-sas, 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-

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 significati-va en la comunicación de información.Con el uso de Blogs y Wikis a nivel empresa-rial, 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 sus-tentados 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 sis-tema receptor podrá entender la información que una aplicación emisora envía, indepen-dientemente 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 suficien-te. También es posible pensar en el lenguaje XML como formato para la comunicación en-tre 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 ca-tegoría en particular.

Cada vez más, hay portales corporativos, por ejemplo: de noticias o periódicos, incluso pági-nas 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, por-que 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 ca-nal de información y recibir actualizaciones en tiempo real directamente en su computadora a través del lector de RSS de su elección (exis-ten otros tipos de lectores de RSS que pueden configurarse para recibir las actualizaciones de información vía correo electrónico, consultan-do una página web, etcétera).

Llegará un punto en que la información po-drá ser usada de varias formas eficientemen-te. 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 responsabilida-des; y por otra parte, podría existir también

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 produci-mos en nuestros equipos de trabajo...

Una Nueva Forma de ComunicaciónUsando Web 2.0 como una Herramienta EmpresarialPor Luis du Solier


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

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

3. Hágalo usted mismo. La posibilidad de ser autosuficiente en tareas sencillas sin depen-der 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 inte-ractuar con la información a través de distintas aplicaciones, para así tener la opción de pre-sentarla a varias personas con distintos privile-gios 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.

La tendencia va hacia la construcción y elabo-ració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 eficien-te y sin necesidad de depender del área de TI, por lo menos para las tareas más comunes.

Escenario en un proyecto de softwareHablemos del potencial de los Blogs en un pro-yecto de desarrollo de software. Imaginemos que, el personal de la organización cuenta con su propio Blog, que contiene información rela-cionada a cada uno de ellos. Por ejemplo: sus habilidades o competencias, los proyectos en los que ha trabajado y en lo que se encuen-tra actualmente. Podríamos renombrar estos Blogs como “Página Personal del Profesionis-ta”. Esto podría ser la base de una estructura que sustentara y permitiera relacionar auto-máticamente a personas, de acuerdo a sus ca-pacidades 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.

¿A dónde voy con esto? Pensemos en definir por lo pronto tres tipos de Blogs: Personales, Clien-tes y Proyectos. Los Blogs tipo Cliente y Proyec-to, 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 relevan-te 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 per-miten 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.



Cuando estamos desarrollando y dando mantenimiento a un producto de software, los cambios son inevita-bles, 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.

Administración deCambios del SoftwarePrincipios y HerramientasPor Ysalia Bautista y Rigoberto Calleja

La incorporación de esos cambios al soft-ware de forma descontrolada, frecuen-

temente 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, nues-tros 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, eventual-mente requerirá que nosotros, o nuestros compañeros de equipo tengan que rehacer parte del trabajo.

Proceso de solicitud de cambiosCualquier organización que desee administrar adecuadamente los cambios al software, se debe asegurar de que los cambios que se pro-pongan 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 im-pacto que tendrá; y autorizar, rechazar o mo-dificar 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 so-lució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 ([email protected]) 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 ([email protected]) 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.

El proceso de solicitud de cambios nos permi-te dar seguimiento a las solicitudes de cam-bio y efectuar mediciones acerca de la activi-dad 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. Finalmen-te, una autoridad establecida evaluará todos los aspectos del cambio propuesto y, aproba-rá, 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 cambiosEl 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 cam-bio, hacer cumplir el flujo del proceso de cam-bios, 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 Ratio-nal ClearQuest, y Microsoft Team Foundation Server. En las siguientes páginas presentamos nuestros comentarios al respecto.

IBM Rational ClearQuestEs una herramienta con la que podemos crear, actualizar, administrar y dar segui-miento 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 ejem-

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

Interfaz de usuarioPara 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 requeri-miento, se requiere introducir información dife-rente que para registrar un nuevo defecto.

Figura 2. El cliente web permite gestionar una

solicitud de cambio

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 co-municación entre distintos repositorios a tra-vés de un esquema de replicamiento.

Reportes y métricasUna solicitud de cambio de ClearQuest cuen-ta con una variedad de atributos: estado, tipo de cambio, severidad, prioridad, área afectada etcétera; que se almacena en un re-positorio del que se puede extraer informa-

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 soli-citudes 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 solicitu-des registradas durante en un trimestre. •Tiempo. Indican cuánto tiempo ha perma-necido un registro en un determinado esta-do, por ejemplo: número de solicitudes que han permanecido en el estado de registrada por más de un mes.

Figura 3. ClearQuest provee una gran variedad

de reportes

Pros•La versatilidad de ClearQuest permite utili-zarla no sólo para administrar cambios, sino para resolver otro tipo de workflows.•Tanto el cliente como el servidor de Clear-Quest, 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 permi-te saber qué campos de la forma se cam-biaron, quién los cambió, cuándo y, en qué acción y estado.

www.softwareguru.com.mx 31MAR-ABR 2007

Figura 1. Ejemplo de ciclo de vida para una solicitud

•ClearQuest cuenta con funciones avanza-das de seguridad como soporte a firma elec-tró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 organizacio-nes más exigentes y complejas.

Microsoft Team Foundation Server (TFS)Es una plataforma de colaboración, que per-mite 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 ExplorerTeam Explorer es el cliente default para inte-ractuar 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

Elementos de trabajoTFS emplea el concepto de elemento de tra-bajo para dar seguimiento a la asignación y al estado del trabajo asociado al ciclo de de-sarrollo. Existen varios tipos de elementos de

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ódigoTFS también administra los cambios al có-digo fuente, de forma tal que, en cualquier momento se pueda saber quién y qué modi-ficó el código; y qué solicitudes de cambio, requerimientos y/o defectos están asocia-dos a dicho cambio. Gracias a este control de código, es posible obtener una versión específica del proyecto, hacer ramificacio-nes (branch) o unir ramas (merge).

Figura 5. El Source Control Explorer permite la administra-

ción de cambio de código

ReportesTeam Foundation incluye un almacén de datos en el que se recopilan los datos operativos que provienen de los elemen-tos de trabajo. Este almacén es emplea-do 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 genera-ciones de producto.

Figura 6. Reportes automáticos listos para usarse

Orientación del proceso, plantillas de proceso y proyectos de equipoVisual Studio Team System como familia de productos, tiene un enfoque hacia pro-ceso. Provee guías acerca de roles, acti-vidades, 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 reali-zarse como parte del proyecto.

Pros•Team Foundation Server no se limita a la administración de cambios, sino que pro-vee una plataforma completa para admi-nistrar el ciclo de vida de software. Esto se traduce en ahorro de dinero y esfuerzo, ya que evitamos la necesidad de integrar va-rios 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 usua-rios concurrentes. Sin embargo, sabemos que para el grueso de las organizaciones en América Latina, esto no es un factor impor-tante, ya que en dicha región, el grueso de las organizaciones de software tienen me-nos de 50 desarrolladores.


ConclusiónAl igual que la mayoría de los pro-ductos de Microsoft, TFS es una herramienta amigable y fácil de usar, orientada hacia la produc-tividad, 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 funcio-nalidad requerida por la gran ma-yoría de los equipos de desarrollo de software.


En días pasados me encontraba revisando un servicio web que había estado desarrollando con ASPs. Mi atención esta-

ba 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 ge-neración y tuve mis dudas con respecto a la programación visual. Y hoy en día trabajo con herramientas WYSIWYG que me permi-ten 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 soft-ware 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 es-tas ideas. El papel del programador, y más en general, el del pro-gramador analista, no ha cambiado mucho desde la invención de las máquinas de Von Neumman: el programador analiza un pro-blema, plantea una solución computacional y codifica un algorit-mo 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

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 hu-mano, 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 pan-tallas y reportes. • Automatizan el trabajo repetitivo, como la ejecución de bate-rías de casos de prueba. • Permiten integrar los diferentes procesos del ciclo de vida de desarrollo de software, con herramientas que, por ejemplo, in-tegran 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 de-sarrollo. 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

El arte dinámico de la programaciónEl 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. Aun-que 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.

// COLUMNA/*CÁTEDRA Y MÁS*/


En el número de SG de julio-agosto del 2005, mi colega Sergio Durán, descri-

bió de manera general el método de Aná-lisis de Puntos de Función, cuyo detalle se encuentra explicado en el Manual de Prác-ticas de Conteo (CPM por sus siglas en in-gles) en la actual versión 4.2. Este manual, se mantiene constantemente por el Interna-tional Function Points Users Group (IFPUG), con el fin de incrementar la repetitibilidad y reproducibilidad en el conteo de las aplica-ciones de software.

Reproducibilidad y repetitibilidadAntes de continuar, recordemos que la re-petibilidad, es la variación que tiene una misma persona contando una misma apli-cación en tiempos distintos, por otro lado, la reproducibilidad es la variación prome-dio 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 des-viación esperada no será mayor al +/-10%. Esto quiere decir que si una aplicación fue-ra medida en 100 puntos de función, por un equipo experimentado en Análisis de Puntos de Función en México, cabría espe-rar que el conteo de la misma aplicación por otro equipo en Brasil, también experi-mentado en el método, fuera entre 90 y 110 puntos de función. En la práctica, esta si-tuación la he verificado varias veces, con-tando aplicaciones para diversos clientes, y comprobando mis resultados con otros equipos totalmente independientes den-tro y fuera de México. Es esta estandariza-ció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 repetibili-dad 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 me-dición, medir y leer el resultado. Al medir la funcionalidad del software, tenemos el problema de que el instrumento de medi-ció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 interpre-tación que cada persona pudiera hacer en la aplicación. Es por esto que el Manual de Prácticas de Conteo del IFPUG, está dividi-do en cuatro secciones: la primera sección incluye las definiciones y reglas de cada uno de los componentes del conteo; la se-gunda sección provee guías y ayudas para el conteo de ciertas situaciones que cau-san ambigüedad en el conteo; en la tercera sección se ofrecen una serie de ejemplos que ayudan a entender y acotar los con-ceptos anteriormente provistos; y por úl-timo, 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 expe-riencia, siendo la certificación como Cer-tified 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 fun-ción en una aplicación Web hipotética.

Planteamiento y requerimientos inicialesUna 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 desarrollado-ra 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 an-temano, 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 funciona-les, 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 acce-sorios de cada uno de ellos. El modelo de datos que maneja es el siguiente:

/* ADMINISTRACIÓN DE PROYECTOS */

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

// PRÁCTICAS

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.

Diagrama 1. Modelo de datos del SIV


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:

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 pre-cio 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•....

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

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:

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 institu-ción financiera. Tal y como se muestra en la pantalla siguiente:

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

de la aseguradora, nombre de la financie-ra, marca del vehículo comprado, modelo, año-modelo, color, accesorios y precio del vehículo. Los datos quedarán almacena-dos en la siguiente tabla:

Aplicación del proceso de análisis de Puntos FuncionalesPlanteado el caso práctico, podemos apli-car 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:

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

“De aplicarse correctamente el método, la desviación esperada no

será mayor al +/- 10%”.

Pantalla 1. Parámetros de Consulta

Pantalla 2. Listado de Vehículos

Pantalla 3. Detalle del Vehículo

Pantalla 4. Captura de Datos para Compra

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

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

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


/* ARQUITECTURA*/// PRÁCTICAS

En el número anterior, dimos a conocer la práctica de evalua-ciones a la arquitectura, durante el ciclo de vida del desarro-

llo 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. Des-pué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 modifica-ció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].

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 es-fuerzo requerido para modificar la arquitectura a cambios requeri-dos 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 ar-quitecturas propuestas y selecciona aquella que proporcione mayor soporte a cambios.

ALMA puede utilizarse una vez que concluye la especificación de la arquitectura (evaluación clásica), o aun cuando la arquitectu-ra 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 eva-luació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 relacio-nes 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

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 pro-babilidad de que ocurran durante la vida operacional del sistema. 4. Evaluar escenarios. Se realiza un análisis de impacto, que con-siste 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.

Performance Assessment of Software Archi-tecture (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 soft-ware 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 apli-cació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 poste-riormente, cuando ya ha sido implementada. Los escenarios gene-

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

Figura 1. Método ALMA

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


/* ARQUITECTURA*/

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 cons-truir modelos de desempeño.

Para utilizar este método, la arquitectura de software debe estar pre-viamente 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 direc-tivos el objetivo de la evaluación, y se explica el método PASA. 2. Presentar la arquitectura. El equipo de desarrollo presenta la ar-quitectura 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. Re-cordemos 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 diagra-mas 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 des-empeño principal, se debe especificar al menos un objetivo de desempeño. Mismos que pueden ser expresados de distintas ma-neras. 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 ar-quitecto y equipo de desarrollo para aclarar dudas. Si existe infor-mación acerca del desempeño del sistema, se colectan métricas.7. Analizar la arquitectura. En este paso se utilizan diferentes téc-nicas 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 desem-peño, se identifican alternativas de solución. Estas pueden incluir el cambio de estilo arquitectónico, modificar la arquitectura para eli-minar anti-patrones de desempeño, o alternativas para optimizar la interacción entre componentes.9. Presentar resultados. Finalmente se elabora un documento

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

Las personas involucradas durante la evaluación son: el arquitec-to, el equipo de desarrollo y en algunos momentos, el gerente(s) de proyecto. Si se realiza de forma intensiva, la evaluación com-pleta 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 arqui-tectura 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 propieda-des 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 siste-ma 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.

Figura 2. Método PASA


/* ARQUITECTURA */// PRÁCTICAS

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 deter-minan los valores para los atributos: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Para reflejar la di-ferencia 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 infor-mació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 presen-cia de patrones o propiedades de facilidad de uso en la arquitec-tura 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 afec-ta a un atributo específico en un escenario de uso. Finalmente, se ex-presan 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.

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

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 en-cuentre 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, fa-llas o accidentes.•Reconocimiento. Es la capacidad de detectar ataques, fallas o acci-dentes, y si estos ocurren, evaluar los daños.•Recuperación. Es la capacidad de mantener en operación los servi-cios 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 escena-rios. El primer tipo son los escenarios normales, que se componen de una serie de pasos donde los usuarios invocan a servicios y obtie-nen 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 siste-ma, se discute el entorno de uso en términos de capacidades y ubi-caciones 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 selec-cionan los servicios esenciales y los activos que usan. Se deben selec-cionar 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 compo-nentes 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 ata-ques, 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 compro-meten 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.

Figura 3. Método SALUTA

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

ConclusionesEn 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 sis-tema. SALUTA, que analizando una serie de atributos de calidad predice

la facilidad de uso; y SNA, que analiza en la arquitectura, la superviven-cia 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.

Referencias1. Bengtsson, PerOlof, Nico Lassing and Jan Bosch, Vliet, Hans van. “Architecture-Level Modifiability Analysis (Alma).” The Jour-nal 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, Soft-ware process improvement and practice: Wiley, 2003.5. Mead, Nancy R., Robert J. Ellison, Richard C. Linger, Thomas Longstaff and John McHugh. “Survivable Network Analysis Me-thod.” CMU/SEI, 2000.


Figura 4. Método SNA

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, requerimien-

tos no funcionales.

Especificación de la arquitectura.

Especificación de la arquitectura, requerimien-

tos no funcionales rela-cionados 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 arquitec-

tura 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 ingenie-ros responsables por la

facilidad de uso.

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

Duración No especificado 7 días No especificado No especificado

Validación del método

Sistemas de control em-bebido, sistemas médi-

cos, 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


/* ESTRATEGIAS DE DESARROLLO */// PRÁCTICAS

Desarrollo Dirigido por ModelosUn Nuevo Paradigma de DesarrolloPor Sergio Cedillo

El 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 posterior-mente, ahonda en la forma en que éste se lleva acabo.

El ambiente de negocios actualLos sistemas de TI no se desarrollan en aislamiento. Su propósito es fa-cilitar 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 pre-supuesto y se espera que demuestren un claro valor al negocio.•Los sistemas de software continúan creciendo en escala y com-plejidad para satisfacer las necesidades del negocio. Las técni-cas 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 gen-te altamente especializada, y las organizaciones sufren para encon-trarlos. 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 organiza-ciones quieren aprovechar los avances en Middleware, pero no quieren reescribir constantemente sus aplicaciones.

Entendiendo la estrategia dirigida por modelosMDD es un estilo de desarrollo donde los principales artefactos de software son modelos, a partir de los cuales se puede generar códi-go 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 ejem-plo, un ingeniero civil crea un modelo de un edificio que le sirve para determinar las posiciones de las cargas.

En MDD se introduce el criterio adicional de que un modelo debe ser interpretado por una máquina. Por ejemplo: debemos ser ca-paces 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.

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 compu-tadora, que le permite su automatización.

Los modelos de software esconden detalles de implantación téc-nica, para que un sistema pueda diseñarse utilizando conceptos de un dominio de aplicación. El diseño de la aplicación, típica-mente 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 aplica-ción utilizando conceptos tales como mensaje, proxy y adapta-dor. Posteriormente se puede refinar el modelo de software y diseñar los detalles de sus componentes.

Los modelos como borradores y planosLa 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 mo-delos 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 especifi-cación es valiosa, pero requiere una disciplina estricta para mante-nerlos 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 implemen-tació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.


Los modelos como habilitadores de la automatizaciónEn MDD, los modelos no son solamente borradores, diagramas o planos, sino artefactos primarios, de los cuales se genera auto-máticamente una implementación. En MDD, los modelos orien-tados 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ódigoLa 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 ne-cesita 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 em-bargo, 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?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 herra-mientas 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.

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 desarro-llar 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 am-biente 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 rea-lizadas en un proyecto tradicional. Las tareas en blanco son las adicionales que construyen las herramientas MDD para un pro-yecto específico.

Se puede construir el ambiente y herramientas MDD, previo al de-sarrollo de la aplicación de negocio, o se puede tomar un método más iterativo, o “justo-a-tiempo”, donde se desarrolla el ambien-te MDD en paralelo a la aplicación. De cualquier manera, es im-portante 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.

TareasLos pasos iniciales para desarrollar herramientas MDD son los mis-mos 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 arquitec-tó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:

Figura 1. Pasos para desarrollar un ambiente MDD

42 MAR-ABR 2007 www.softwareguru.com.mx42 MAR-ABR 2007 www.softwareguru.com.mx

•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 compo-nentes. 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 arte-factos 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 planti-lla para cada tipo de artefacto diferente, basándose en los artefactos muestra desarrollados previamente.•Diseñar, codificar y probar transformaciones y patrones. Para cada pa-tró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 desarro-llo. En algunos casos, incluso sería justificable empaquetar las herra-mientas 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 desarrollado-res de la aplicación las utilicen. Lo que sigue es entrenar a los desa-rrolladores de la aplicación para utilizar las herramientas, y entonces desarrollar las aplicaciones de negocio.

La cadena de herramientas MDDLa 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 ne-gocio y selecciona un patrón de diseño. Esto aloja un modelo de di-seño, y el desarrollador llena en detalle las funciones específicas del negocio que está construyendo. Posteriormente, el proceso de desa-rrollo es completamente automatizado. El desarrollador selecciona una opción para generar los artefactos, los cuales son empaqueta-dos y colocados en el área de construcción. Entonces, el desarro-

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

ConclusiónEn 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écni-ca 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 comuni-cación, y captura del conocimiento. Sin embargo, la estrategia debe apli-carse 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

/* ESTRATEGIAS DE DESARROLLO */// PRÁCTICAS

Figura 2. La Cadena de Herramientas MDD

“En MDD, los principales arte-factos son modelos, a partir de los cuales se puede generar código y

otros artefactos”.


// UML

Componiendo lo DescompuestoDiagrama De estruCtura CompuestaPor Sergio Orozco

En el mundo real –el mundo de los ob-jetos–, es muy común encontrarnos con objetos que están compuestos por más objetos. UML nos permite modelar dicha in-formación por medio de relaciones de com-posició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 dia-grama 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 de-terminado en el tiempo.

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

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 propul-sor 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 llan-tas que mueve el motor en el carro son las delanteras, y no las dos traseras.

Para modelarlo correctamente en un dia-grama de clases, tendríamos que elabo-rar toda una jerarquía de herencia entre clases, para distinguir entre los motores de barcos y carros; y entre las llantas del-anteras y traseras de un carro, o marcando dependencias entre las relaciones. Esto se muestra en la figura 3.

Agregando contexto en UML 2Con 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 acla-remos 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. [email protected] www.milestone.com.mx

Figura 1.

Figura 2.

Figura 3.

43ENE-FEB 2007www.softwareguru.com.mx

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.

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.

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

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 ha-cia otra parte. Se muestran como pequeños cuadrados al final de un conector entre dos partes. No son obligatorias, pero son reco-mendables si se quiere encapsular el funcio-namiento 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.

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.

Figura 4.

Figura 5.

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

La industria global de software en 2006 fue estimada por Micro-soft en 131 billones de dólares. El total de la industria de pub-

licidad 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 TIEl 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 pu-blicidad. 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 crecimientoHay 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%).

Capitalizando la oportunidadHoy la publicidad en línea representa sólo 5% del mercado to-tal; si pudiéramos crecer en 2007 a 8%, se estarían captando 15 nuevos billones de dólares. Querámoslo o no, esto traerá conse-cuencias 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 ten-drá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.

ConclusionesEl 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


El Futuro Ti está en el Consumidor FinalEstimulando la Imaginación

/*TENDENCIAS EN SW*/// COLUMNA

Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de adminis-tració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


Hace ya por lo menos diez años, la Web irrumpió en nuestras vi-das. Son ya muy lejanos aquellos tiempos en los que la web, no era mas que un repositorio de páginas estáticas que servían como carta de presentación a las empresas, y personas. Hoy en día, la web es escencialmente una plataforma para todo tipo de aplicaciones, con todo tipo de propósitos: desde tien-das virtuales hasta redes sociales.

Desde su inicio, nos hemos dado cuenta que el desarrollo web tiene características particula-res. 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 habili-tan (HTML, JavaScript, XML, ASP, PHP, JSP, JSF, RoR, y la lista continúa...). Esta situación de encontrarnos con una plataforma con caracte-rí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 aplica-ciones como Dios les dio a entender.

De hecho, Roger Pressmann en su libro: “Software Engineering: A Practitioner’s Approach”, que es una de las biblias de la in-geniería de software, comenta lo siguiente:

“Cualquier producto o sistema importante es merecedor de recibir una ingeniería. Esto sig-nifica 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 avan-zando, y disponer de mecanismos para asegu-rar la calidad del resultado final. Muchos de los que desarrollan en web no opinan lo mismo;

ellos piensan que su mundo es realmente dife-rente, y que los enfoques de ingeniería de soft-ware convencionales no aplican para ellos”.

Es de esta necesidad de una estrategia sistemá-tica, pero que tome en cuenta las características especiales del web, que surge la denominada: Ingeniería Web. San Murugesan la define como la aplicación de un enfoque sistemático, disci-plinado y cuantificable para el desarrollo exito-so de aplicaciones web de alta calidad.

¿Qué particularidades tiene el desarrollo web?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 com-pleto la ingeniería. Entre las particularidades más significativas podemos listar:•Residente en red. Una aplicación web re-side en una red, y debe dar servicio a una comunidad diversa de clientes.•inmediatez. Se refiere al corto tiempo que nor-malmente tienen los proyectos web para termi-nar, o por lo menos, lanzar una versión inicial.•Evolución continua. A diferencia del soft-

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

Atributos de calidad en la web¿Cómo saber que nuestro sitio web es de cali-dad? 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 acercar-nos 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:

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

// FUNDAMENTOS

Lacendi Nolasco Calderón es Ingeniero en Desarrollo de Software egresado de la Universidad Madero. Ha sido ponente en Congresos de Software y Cien-cias 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.

Figura 1. Requisitos de calidad para aplicaciones web

El proceso de ingeniería webComo ya vimos, las aplicaciones web tie-nen 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 in-cremental. Esto como respuesta a la conti-nua evolución de las aplicaciones web, así como el corto tiempo en el que normalmen-te 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 delimi-tamos el alcance de la primera iteración.•Planificación. Una vez planteado el pro-blema, podremos estimar costos, riesgos y esfuerzo durante el desarrollo. Recorde-mos que en la planeación iterativa sola-mente se detalla la iteración actual, y las iteraciones subsecuentes sólo se plan-tean de forma general.•Análisis. Durante esta etapa establecemos los requerimientos técnicos, gráficos, y de con-tenido, que incorporaremos en la iteración.•ingeniería. La actividad de ingeniería in-corpora dos grupos de tareas que se rea-lizan 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 ge-nere correctamente, utilizando las planti-llas, interfaces y contenidos diseñados en la fase de ingeniería. Posteriormente se realizan las pruebas pertinentes, que de-penderán del tipo de aplicación y reque-rimientos 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-

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

No reinventar la ruedaUna regla de oro en el desarrollo de cual-quier 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 mu-chos frameworks y engines que se pueden adaptar fácilmente a nuestras necesida-des. 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 ele-mentos existentes tanto dentro como fue-ra de nuestra organización.

ConclusionesLa ingeniería web se ha convertido en una necesidad para el desarrollo de aplicacio-nes 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

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

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 cum-plimiento de los objetivos generales.

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

“El beneficio del uso de la ingeniería web es que se asegura la correcta ejecución y

terminación de cada proyecto.”

Figura 2. Modelo del Proceso IWEB



El valor de la información lo define uno mis-mo, 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 al-macenada 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úme-ro 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 disposi-tivos portátiles.•Cuando el ataque viene desde adentro de la empresa.

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 causa-do por los virus de computadora.

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

Últimamente, los crackers utilizan una técnica de: “secuestro de información” de computa-doras 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 pro-tección de sus productos para evitar la pira-tería usando candados en hardware, mejor conocidos como Sentinel Ultra Pro, pero po-

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

La solución: criptografíaPara mantener la privacidad e integridad de la información, se recomienda una pro-tecció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 es una técnica eficiente uti-lizada 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 ac-tual utiliza algoritmos matemáticos que se aplican al dato, impidiendo su lectura (en caso de no ser el propietario de la informa-ción), y utilizan llaves de encripción y decrip-ción para tal efecto.

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

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

Los datos son un activo de vital importancia para las empresas modernas. De hecho, cada vez encontra-mos 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.

Encripción de DatosLa última Línea de DefensaPor Roberto González

// INFRAESTRUCTURA

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.


•Impedir el acceso a usuarios no autoriza-dos 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, centrali-zada 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íaLa solución ideal debe ser capaz de soportar los dos esquemas de criptografía más comu-nes: en Llave Simétrica y Llave Asimétrica.

La criptografía en Llave Simétrica usa una misma llave para encriptar y decriptar la in-formación, aquí se puede aprovechar el al-goritmo 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 infor-mació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 con-siste 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 da-tos, se comparte con los usuarios con los que se intercambia información.

•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 solucionesExiste 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á encrip-tar 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 regulacionesDebido al constante robo de información, en muchos países del mundo se han creado re-gulaciones que obligan a empresas privadas, sobre todo del sector financiero y, a institu-ciones 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 Fede-ral Privacy (Australia), y European Data Protection Act (Europa).

Pero, ¿por qué esperar a una imposición? ¿Si su organización maneja información sensi-ble?, –y prácticamente cualquier organiza-ción lo hace–, entonces les recomiendo que seriamente consideren adoptar una solución de criptografía de información.

Elección de proveedores y productosEn realidad, no hay muchas alternativas en el mercado que nos puedan ofrecer soluciones de cifrado con altos niveles de encripción y des-empeñ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 certifi-cación en cualquier nivel que se otorga a este tipo de productos, como FIPS, EAL o CCEAL.

ConclusiónSin duda, las tecnologías de informa-ción, la implementación de regulaciones y de políticas, y su ejecución, son ele-mentos 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 inte-gración de esquemas de criptografía, que nos dan como resultado esa “úl-tima línea de defensa” para proteger la información confidencial.

“Existe un amplio rango de soluciones de criptografía, que varían dependien-

do de las necesidades del usuario”.


/* GADGETS */// TECNOLOGÍA

Sony

Micro PC UX Premium Series VGN-UX390NMá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 escri-tura, y además incorpora un par de cámaras para capturar imágenes o hacer videoconfe-rencias. 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 preinsta-lados 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.

// TECNOLOGÍA

Voodoo

Middleweight Envy a:538Cada vez son más las empresas que ofrecen equipos personalizables, las máquinas de Vo-odoo (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.

Logitech

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

SanDisk

Sansa ExpressDel 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, sinto-nizador 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 Ex-press soporta hasta 3GB de música o 750 can-ciones utilizando una tarjeta microSD de 2GB, que también permite transferir de forma segura a otros dispositivos compatibles, tales como te-léfonos celulares o PDAs. Trabaja, a su vez, con los formatos más populares de música digital, y es compatible con Windows Vista.


/* GADGETS */// TECNOLOGÍA

Super Talent

OvelockingEste fabricante de módulos de memoria DDR y DDR2 y dispositivos de almacenamiento Flash para computa-doras 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.

DUALphone

Skype 3088Por fin, el teléfono ideal para hacer llamadas locales y sobre IP mediante el sistema Skype. Después del primer modelo, que re-querí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, eliminan-do 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 te-lé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 memo-ria, aunque es posible hacer un login distinto para cada sesión, y cambiar manualmente entre líneas —convencional o de Sky-peOut— 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áticamen-te; 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.

YamahaYSP-1100 Digital Sound ProjectorPara 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 disposi-tivo 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.

Koss

Cobalt Wireless HeadphonesAunque 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 au-dio 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 pue-den conectar a cualquier equipo mediante un transmisor de mi-niplug o un accesorio USB, o a través de paridad con un emisor Bluetooth, sea un teléfono celular o computadora. Son recarga-bles 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ífo-nos 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.


Al 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, es-trella más grande del movimiento en nuestro país. También podemos pensar en aquellos que organizan tantos congresos anuales de soft-ware 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 di-fiere 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 sa-tisfacció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 or-ganización sin fines de lucro, cuando le sugerí apoyarse en un pro-grama 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 estudian-tes 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 tie-nen oficinas, no tienen financiamiento, pero sí tienen una buena red de contactos que constantemente los expone a proyectos donde pue-den 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 Ay-zax, tres de sus principales miembros, son ya muy conocidos en el

circuito universitario. Se han dado a la tarea de llegar a los muy jóve-nes 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 embar-go, ambos han elegido bajar el movimiento del software libre de los cielos de las vacas sagradas, a nuestras secundarias. Así que la pre-gunta es, ¿qué estamos haciendo nosotros, los experimentados, por ayudar a las nuevas generaciones?

Es aquí donde creo que podemos hacer algo dentro de nuestras or-ganizaciones. La propuesta es muy sencilla: abandonemos el degra-dante 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, rea-licemos proyectos de tecnología aplicada a beneficio social, involu-crando 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 so-mos 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 po-damos 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 bus-can, 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 profesio-nistas, 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 lideraz-go, y el mejor liderazgo es el que enseña a ser proactivo y auto-dirigido. 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 comer-ciales 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

Desarrollando Nuevos Talentos con Software LibreEs Momento de Bajarse de la Nube

/*TIERRA LIBRE*/// COLUMNA

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

INDEX

Anunciante Páginas Sitio

AMCiS 55 www.amcis.org.mxAvantare 45 www.avantare.come-Quallity 47 www.e-quallity.netintersoftware F2 www.intersoftware.com.mxiDC F3 www.idc-eventos.comitera 17 www.itera.com.mxMicrosoft 13 www.microsoft.com/mexicoMilestone Consulting F4 www.milestone.com.mxRoca Sistemas 01 www.rocasistemas.com.mxSafeNet 07 www.safenet-inc.comSofttek 43 www.softtek.comSun Tech Days 11 www.suntechdays.com.mx

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

DIRECTORIO

www.softwareguru.com.mx MAR-ABR 2007 57

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 to-dos hicieron lo que tenían que hacer para ser hoy potencia mun-dial en la industria del software.

Ahora volvamos al presente. El Gobierno Federal, junto con algu-nos 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.

Podrá haber quienes estén a favor o en contra de esta asevera-ció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 para-guas 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.

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

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 continui-dad 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 outsour-cing para resolver sus necesidades.

Estamos siendo testigos del nacimiento de una industria que en corto plazo representará una porción significativa del PIB mexi-cano. 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 to-dopoderoso 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.

Esto no es futurismo, esto está sucediendo. India ya tomó con-ciencia, 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 direc-tivos a elegir locaciones para instalar sucursales de sus fábricas en México.

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.


El Nacimiento de una EstrellaLa Industria Mexicana del SoftwarePor Leonardo N’Haux

// REFLEXIONES

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

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

Mar

zo-A

bril

200

7

[ Fundamentos ]Ingeniería Web

Noticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

Año

03

No.

02

SG14 (Marzo-Abril 2007)

Documents

Transcript of SG14 (Marzo-Abril 2007)