METODOLOGÍAS ÁGILES. La Industria en cifras CIMAT. Software Guru CONOCIMIENTO EN PRÁCTICA Año 02 No.03 Mayo-Junio

Transcripción

1 Requerimientos Service Level Agreements Arquitectura de Software Software Guru CONOCIMIENTO EN PRÁCTICA Año 02 No.03 Mayo-Junio ESPECIAL La Industria en cifras [ UML ] Diagramas de estado METODOLOGÍAS ÁGILES [ ENTREVISTA ] Carlos Montes de Oca CIMAT Noticias Eventos Fundamentos Reflexiones Tecnología Carrera [ PROGRAMACIÓN ] Spring

2

3

4 DIRECTORIO A > EDITORIAL Edición Ejecutiva Pedro Galván Coordinación Editorial Mara Ruvalcaba Edición y Producción Edgardo Domínguez Arte y Diseño Oscar Sámano, Dafne Ortega Existen muchas cosas que llaman la atención sobre las metodologías ágiles. Lo primero, es que al parecer ya no es necesario referirse a ellas como metodologías ágiles, sino que ya se utiliza el término Ágil (con mayúscula y en singular) para referirse a este conjunto de métodos y la filosofía que representan. Bueno, habiendo aclarado ese punto, hagámonos la pregunta del millón: De qué se trata Ágil? Algunos conocedores podrían decir que Ágil se refiere a una forma innovadora de desarrollar software, basada en prácticas como el desarrollo iterativo, entregas continuas, programar antes de probar, involucrar al cliente y que contrasta con la forma tradicional de desarrollar software, en cuanto a que es mucho más flexible y adaptable, por lo que se adecúa mejor a proyectos innovadores. Esta sería una respuesta válida. Sin embargo, a nuestro juicio no menciona la esencia de Ágil. Y es que la esencia de Ágil es la gente. Así es, después de décadas de dedicarnos a generar tecnologías, herramientas, modelos y procesos que soporten el desarrollo de software, nos estamos dando cuenta que la base del desarrollo de software, son las personas. Ja, de haberlo sabido antes, hubiera estudiado psicología! Hay muchísimo que podemos aprender de las metodologías ágiles. Pero en lugar de perdernos en asuntos como si se debe programar en pares o no, o si es adecuado generar builds cada dos horas, debemos estar conscientes de que todas las prácticas de Ágil existen por una simple y sencilla razón que acostumbramos olvidar: el software es desarrollado por personas. Agradecemos el entusiasmo de todos los colaboradores que se interesaron en participar en este número. Mil gracias a Carlos Montes de Oca por compartir con nosotros su visión sobre la academia y la industria en que operamos. Por último, les recordamos que pueden enviar cualquier propuesta de contenido, o retroalimentación a editorial@softwareguru.com.mx. Gracias, y que disfruten este número. Equipo Editorial Consejo Editorial Francisco Camargo, Guillermo Rodríguez, Ralf Eder y Raúl Trejo, ITESM CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek.; Luis Vinicio León, e-quallity - ITESO Colaboradores Luis Daniel Soto, Ariel García, Paulina Olivares, Ariel Súcari, Dora Luz González, Luis Guerrero, John Gómez, Mónica Vázquez, Axel Nissim, Domingo Suárez, Luis Felipe Fernández, Sergio Orozco, Eugenio Torres. Ventas Claudia Perea Marketing Natalia Sánchez Distribución Daniel Velázquez Ilustración de Portada Tollhaus Contacto info@softwareguru.com.mx SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P , Naucalpan, México. 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: Certificado de licitud de título: Certificado de licitud de contenido: ISSN: Registro Postal: PP Se imprimió en abril de 2006 en Litográfica Roma. Distribuido por Sepomex. 02 MAY-JUN

5 contenido may-jun 2006 Año 2 número EN PORTADA Métodos Ágiles Lo ágil es lo de hoy. Conozcamos los principios de los métodos ágiles, así como los mitos y realidades asociados a ellos. Industria Mexicana 16 de Software en Cifras Productos LO QUE VIENE 12 Microsoft Atlas, NetBeans Enterprise Pack, Oracle SQL Developer HERRAMIENTAS 14 Desarrollo Dirigido por Pruebas Columnas Tejiendo Nuestra Red 08 por Hanna Oktaba Mejora Continua 10 por Luis Cuellar Cátedra y Más 30 por Francisco Camargo Tendencias en Software 39 por Luis Daniel Soto Prácticas ADMÓN de PROVEEDORES 32 Service Level Agreements, Parte 2. En la segunda parte de esta serie, Axel Nissim comparte lineamientos y recomendaciones para desarrollar acuerdos de nivel de servicio, desde la perspectiva del proveedor. REQUERIMIENTOS 34 El ABC de un Taller de Requerimientos Mónica Vázquez nos guía a través de lo que se debe hacer para realizar un taller de requerimientos exitoso. PROGRAMACIÓN 36 Desarrollo JEE Ágil con Spring Domingo Suárez nos explica algunas debilidades de JEE, y como sobreponerlas con Spring. ARQUITECTURA 40 Arquitectura de Software Luis Felipe Martínez nos habla sobre los orígenes y trascendencia de la arquitectura de software. UML 45 Diagramas de Estado Sergio Orozco nos enseña como modelar el estado de un objeto. Entrevista 20 Carlos Montes de Oca En Cada Número Noticias y Eventos 04 Reportaje 06 Fundamentos 46 Carrera 48 Infraestructura 50 Reflexiones 54 MAY-JUN

6 NOTICIAS Noticias Gartner Enterprise Integration Summit El pasado 5 y 6 de abril, Gartner realizó en la Ciudad de México su Enterprise Integration Summit, donde se manejaron temas sobre de Integración de Aplicaciones, Servicios Web, SOA y BPM. Los analistas de Gartner compartieron su análisis del mercado, las principales tendencias, y lecciones aprendidas, e hicieron diversas recomendaciones para las organizaciones involucradas o prontas a iniciar proyectos de este tipo. Entre las empresas patrocinadoras estuvieron Sterling Commerce, IBM, Oracle, Microsoft, Software AG, Axxis, y otras más. En comparación con la cumbre de Gartner del año anterior relacionada con los mismos temas, este año percibimos que los asistentes ya tenían una mucho mejor idea de temas como BPM y SOA, y en varios casos ya tenían en curso iniciativas de este tipo. Adicionalmente, los proveedores también reflejaron una mayor madurez en cuanto a su oferta. Azertia México obtiene el nivel 3 CMMI En diciembre pasado, Azertia México logró la acreditación en el nivel 3 de CMMI (Capability Maturity Model Integrated) del Instituto de Ingeniería de Software (SEI) tras realizar la evaluación formal en sus áreas de proyectos cerrados (soluciones) y fábrica de software, que se encuentra en Cuautitlán, Estado de México. Con esta evaluación, Azertia se convirtió en la segunda empresa en México en obtener este nivel de CMMI, lo cual pone de manifiesto la capacidad técnica, de gestión y de calidad que posee en el desarrollo y mantenimiento de aplicaciones de software, tanto en la línea de proyectos cerrados como en la fábrica de software. Azertia es una compañía multinacional originaria de España y perteneciente a Corporación IBV (BBVA e Iberdrola), dedicada a ofrecer servicios de TI. Cuenta con centros de trabajo en diversas localidades de España y Latinoamérica. Mayor información en Magnabyte alcanza nivel 2 de norma mexicana basada en MoProSoft Después de un proceso de implantación del modelo MoProSoft y un seguimiento interno, Magnabyte se convirtió en la primera empresa dictaminada por NYCE bajo el nivel 2 de la norma mexicana aplicable para la verificación de procesos de Tecnologías de Información NMX-I-059/02. Dicha norma está basada en el modelo MoProSoft, que busca llevar a las empresas mexicanas a alcanzar niveles internaciones en capacidad de procesos, y mide el nivel de madurez de 9 procesos que corresponden a las capas de Alta Dirección, Gestión y Operación. El participar en este modelo resultaba indispensable para nosotros, ya que creemos firmemente en la capacidad que existe en México de crear software de alta calidad así como en el Programa para el Desarrollo de la Industria del Software (ProSoft) de la Secretaría de Economía, el cual se alinea a nuestros objetivos de negocio, como convertirnos en una empresa líder latinoamericana en la industria de software, desarrollar soluciones de alta competitividad y generar empleos para profesionistas mexicanos, indicó Oscar Flores, Director General de Magnabyte. Mayor información en SigmaTao ya es CMMI 3 Otra empresa que recientemente logró su acreditación en el nivel 3 de CMMI es Sigma- Tao Factory, fábrica de software mexicana ubicada en Querétaro. Esta evaluación de reconocimiento internacional, se suma a las anteriormente obtenidas (CMM-5 y Java Center of Excellence) y ubica a Sigma Tao en el mercado mexicano como parte del selecto grupo que ha obtenido este grado de evaluación, a la vez que confirma su compromiso con la calidad y excelencia en sus productos, así como en los procesos de ingeniería software que los generan. SigmaTao tiene actualmente 540 Ingenieros altamente capacitados y que proveen servicios a las más grandes empresas e instituciones del pais. SigmaTao es parte de EIDON Software, corporativo que incluye a Zentrum (Cmm-3), Blitz (Cmm-3) y ASPEL (Cmm-2) teniendo en total más de 1,700 profesionales dedicados al desarrollo de soluciones de software de alta calidad. 04 MAY-JUN

7 Eventos 13 Mayo 2006 Debian Day Centro Vacacional IMSS. Oaxtepec, Mor. es.debconf.org/debianday 14 y 21 Mayo 2006 DebConf6 Centro Vacacional IMSS. Oaxtepec, Mor. debconf6.debconf.org 16 y 17 Mayo va Conferencia Anual Information Security Hotel Camino Real, Ciudad de México Tel: (55) Mayo 2006 Congreso de Software Libre GULEV 2006 Museo del Transporte. Xalapa, Veracruz 25 Mayo 2006 IDC Service Oriented Architecture Seminar Hotel Presidente Intercontinental Monterrey, NL Tel: (55) y 26 Mayo 2006 Optimizando los servicios de TI con ITIL e ISO y Automatizando la administración de TI con ITSM 25 de Mayo - Ciudad de México, 26 de Mayo - Monterrey, NL Tel: (55) de Junio 2006 IDC IT Security & Business Continuity Conference 2006 Centro Banamex, Ciudad de México Tel: (55) de Junio TCDS BPM Executive Day 2006 Ciudad de México Tel: (55) y 28 de Junio 2006 Gartner 2nd Annual Outsourcing Summit Centro Banamex, Ciudad de México Tel: (55) diseñar, desarrollar y probar sistemas para automóviles. Lo que estamos tratando de hacer aquí es vincular a tres sectores muy importantes para México, nada menos que la electrónica y automotriz, con la que yo considero la más estratégica, que es tecnologías de información y comunicaciones mencionó Eduardo Ramírez, Director de Soluciones Tecnológicas, la empresa mexicana con la cual el ITESO firmó el convenio que originó este proyecto. Fox inauguró el Centro de Tecnología Electrónica Vehicular del ITESO El pasado 9 de marzo el presidente de México, Vicente Fox inauguró en el ITESO, Universidad Jesuita de Guadalajara, el Centro de Tecnología Electrónica Vehicular (CTEV). El objetivo de este proyecto es establecer un centro donde concurran los sectores automotriz, electrónico y de software, para El centro está ubicado dentro del edificio de Tecnologías de Información del ITESO, en un espacio de 425 metros cuadrados. Se creó con una inversión de cinco millones de pesos, de los cuales el 25 por ciento corrió a cargo del Gobierno federal, a través del fondo ProSoft, otro 25 por ciento lo aportó el Gobierno Estatal, a través del Consejo Estatal de Ciencia y Tecnología de Jalisco (Coecytjal), y el 50 por ciento restante fue aportado por el ITESO y Soluciones Tecnológicas. MAY-JUN

8 CLUSTERS Una Solución Integral Esta asociación civil sin fin de lucro, formada hace cinco años y constituida en la segunda mitad del 2004, busca explotar las ventajas de su ubicación geográfica y constituir al estado de Baja California en un Cluster líder en México en el desarrollo de empresas de TI, para fomentar la exportación de servicios, principalmente al vecino país del norte. La principal estrategia de IT@baja es promover proyectos que permitan impulsar el crecimiento de las empresas ya instituidas, y la creación de nuevas, para fomentar una alta competitividad en el estado que lleve eventualmente a un grado de excelencia a los distintos proveedores de servicios y productos de TI, lo que consolidará al estado como una alternativa real para empresas norteamericanas en busca de soluciones integrales. Aprovechando la proximidad con los Estados Unidos, y el huso horario compartido con California, este Cluster ofrece gente y empresas que conocen perfectamente la cultura de negocios e incluso laboral de las compañías estadounidenses, además de que dominan el idioma inglés, lo que representa una ventaja definitiva para ganar la preferencia de las empresas que buscan una alternativa viable en término de costos y valor agregado, sin sacrificar calidad. Antecedentes y Funciones A finales del 2002, como resultado de un estudio para definir las competencias del estado de Baja California. se establecieron los esquemas, conformación y estrategia del Cluster necesarias para dirigir el desarrollo del sector de tecnologías de información en este estado. En una etapa inicial, se optó por concentrarse en el desarrollo de software y promoción de las aplicaciones existentes en el estado. Entre las funciones de IT@Baja están: Ejecutar las estrategias de promoción, capacitación, certificación, vinculación, legal, fondeo, etc. Promover la integración continua de las empresas de este ramo a través de los organismos que las representan. Promover proyectos de subcontratación de desarrollo de software. Buscar el entrenamiento y capacitación continua de sus integrantes. Estandarizar la aplicación de metodologías entre sus integrantes. Vinculación con organismos similares en México y otras regiones, principalmente en el Estado de California, en donde existe una demanda muy importante de subcontratación de desarrollo de software. Vigilar la imparcialidad de asignación de oportunidades de negocio y proyectos internos mediante el código de ética y estatutos del cluster. Conceder el uso de la marca a empresas que tengan la certificación de calidad. Proveer un espacio físico para reuniones estratégicas. Promover la innovación e incubación de negocios, a través de centros de desarrollo de tecnologías de información. Logros y Metas Dentro de los principales logros a la fecha, IT@baja ha promovido continuamente la interacción de las compañías integrantes del Cluster, conformando varias asociaciones, programas y comunidades. He aquí algunos ejemplos: Asociación de Profesionales de IT. Centro de Excelencia Tecnológica en Estándares Abiertos. Comisión Académica e Industria. Modelo de Desarrollo CT Connect. Comunidad.Net. A la fecha, IT@Baja cuenta con 43 socios activos, que reunen una facturación superior a los 28 millones de dólares en Esto representa más del 60% de la facturación de las empresas de software en Baja California. Dentro de los planes de vinculación académica, se creó un programa de capacitación y certificación de maestros universitarios en tecnología.net y Java, además de impartir un taller de MoProSoft y un diplomado de Pruebas de Software. Se formalizó un convenio de colaboración con la Universidad Autónoma de Baja California (UABC), con el que se pretende lograr un programa de extensión académica y conformar una plan de acción para el crecimiento de los egresados en las empresas vinculadas al Cluster. Entre las principales metas de IT@baja están: Iniciar la promoción del Cluster a nivel regional, nacional e internacional. Promover el soporte gubernamental a organizaciones. Soporte y alineación de intereses con el sector académico. Incrementar la membresía. Desarrollar comisiones internas. Desarrollar talleres internos y externos. Atraer socios de clase mundial. Actualizar y promover proyectos y programas a partir de iniciativas de sus integrantes. Atraer nuevas inversiones y fondos hacia el desarrollo de TI en el Estado. Las Empresas La asociación está constituida por distintos representantes que tienen algún tipo de relación con el sector de tecnologías de información de Baja California; empresas de desarrollo de soluciones a la medida, proveedores de soluciones contables, administrativas, de recursos humanos, de comercio exterior, ERPs, etc., proveedores de software a la medida y de infraestructura tecnológica. Los integrantes hasta la fecha son: Grupo Red, Nettss, Prisma Computación, Grupo SyS, Coordenada, SITSA, Telecomm, Everest, G-H & T, BTS, RT Solutions, SmartBC, Cybercorp, Betta Global Systems, LIDA- SA, Aprovi, GM Consultores,, Tecnología Educativa, EYS, Condete, Infosyst S.C., Intelligence Learning, Imacor, Aster, Interfase Mircrosystems, Arkus, Gr Soluciones, Grupo Tress, Zentrum, Nexus, INTEGRA, Business Ware, Gr Soluciones Computacionales, Condete, Central Software y 4 Integradoras: INTUARE, SDS,iMedis e INTAN. Asamblea en Mexicali, Marzo MAY-JUN

9

10 TEJIENDO NUESTRA RED COLUMNA Historia y Futuro de la Ingeniería de Software Visión de Barry Boehm Para cuando lean esta columna, probablemente ya se habrá llevado a cabo la International Conference on Software Engineering (ICSE 06) en Shanghai, donde Barry Boehm participará como conferencista, y en su plática presentará su visión de la perspectiva histórica y el futuro de la Ingeniería de Software. Así que conociendo la importancia de este personaje y el impacto de sus opiniones, les comparto un pequeño resumen del artículo que Boehm desarrolló para esta ocasión y que nos hizo llegar a los miembros del IPRC (International Process Research Consortium). El autor empieza por darnos su definición de la Ingeniería de Software:... es la aplicación de la ciencia y las matemáticas a la construcción del software de tal forma que sus propiedades lo hacen útil para las personas. Lo que me llama la atención en esta definición es el énfasis en las propiedades de software útiles para el cliente. Esto nos habla de calidad del software, pero no desde una perspectiva de actividades como otras definiciones, sino del valor generado para el cliente. Posteriormente, el artículo hace una retrospectiva sobre la ingeniería de software desde los años cincuenta hasta la época actual, y termina con predicciones para el próximo par de décadas. Veamos entonces los puntos más significativos: Años Cincuenta Se aplica al desarrollo de software el mismo proceso que al desarrollo de hardware, tipo cascada rigurosa. Las lecciones aprendidas fueron las siguientes: Buenos principios No ignorar matemáticas, ciencias de la computación, sociales, económicas y administrativas. Usar el método científico para aprender a través de la experiencia. No comprometerse demasiado antes de entender la complejidad de un proyecto Evitar Seguir demasiado rigurosamente el proceso de desarrollo secuencial. Sesentas El desarrollo de software es artesanal. Las propiedades de software, tales como: fácil de modificar, fácil de copiar, no se gasta, es invisible, fomentaron el proceso de desarrollo tipo codifica y corrige (code and fix). Se inició la cultura del hacker en el buen sentido de la palabra, es decir experto en programación, y la del vaquero (cowboy) que hace desarrollos heroicos de última hora. Buenos principios Atreverse a hacer prototipos novedosos, no limitarse a repetir lo que ya se conoce. Respetar que el software es diferente. No se puede incrementar la velocidad de su desarrollo de manera infinita. Evitar Programación al estilo vaquero. Parches de último minuto o trabajo de última noche pueden traer graves consecuencias. Setentas Se identifican las diferentes fases del desarrollo: requerimientos, análisis, diseño, codificación y pruebas. Se introduce la programación estructurada y métodos formales para especificar software. Se identifican principios de diseño, como modularidad, encapsulación, abstracción de tipos de datos, acoplamiento débil y alta cohesión, entre otros. Se publica el modelo de cascada y se definen los conceptos de verificación y validación. Buenos principios Eliminación temprana de defectos y su prevención a través del análisis de causa. Determinación temprana del propósito de sistema para tener una visión compartida con el cliente. Evitar Desarrollo descendente (top-down) a toda costa. Los requerimientos emergentes y los cambios lo hacen poco realista, para la mayoría de los casos. Ochentas Se busca la productividad y escalabilidad de sistemas y equipos de desarrollo. La Orientación a Objetos renace con fuerza a través de las múltiples propuestas de lenguajes de programación. Se crea el primer modelo de madurez de capacidades de procesos (SW-CMM) y los primeros estándares. Nace el concepto de Fábricas de Software y se generan las primeras herramientas para incrementar la productividad a través de la programación por el usuario, tales como 4GLs. Buenos principios Hay muchos caminos para incrementar la productividad que incluyen la selección del personal, capacitación, herramientas, reutilización, mejora de procesos, entre otros. Lo que es bueno para el producto es bueno para el proceso, por ejemplo: arquitectura, composición y adaptación. Evitar Pensar que existe una solución mágica (silver bullet) que aplica a toda clase de problemas. Noventas La concurrencia (paralelismo y distribución) adquiere mayor importancia con respecto a procesos secuenciales. La Orientación a Objetos se extiende a las fases de análisis y diseño. Se acuerda un lenguaje de modelado (UML) y se genera el primer proceso comercial de desarrollo orientado a objetos (RUP). Los diseñadores y los arquitectos de software empiezan a recaudar las mejores experiencias a través de patrones de diseño y de arquitectura. Se define el Modelo Espiral para el desarrollo basado en el análisis de riesgos y su vertiente conocida como desarrollo iterativo e incremental. El Software Libre toma fuerza y se crean los primeros ejemplos exitosos. La usabilidad de sistemas se convierte en el foco de atención e investigación. Software empieza a ocupar la posición crítica en el mercado competitivo y en la sociedad (web). Buenos principios El tiempo es dinero. La gente invierte en software esperando retorno de inversión, mientras más rápido se desarrolle el soft- 08 MAY-JUN

11 ware, más rápido se recupera la inversión, pero eso pasa sólo en el caso cuando la calidad de software es satisfactoria. El software tiene que ser útil para la gente, es la parte crucial de la definición de Ingeniería. Evitar Hacer las cosas demasiado rápido. Los hitos muy ambiciosos a menudo traen como consecuencia las especificaciones incompletas, que resultan en mucho re-trabajo. Situación Actual Los temas nuevos son la agilidad en el desarrollo y el valor para el cliente. Se redacta el Manifiesto de Agilidad en respuesta al estilo promovido por CMM. Surgen nuevos dispositivos (PDAs, celulares) que involucran el ciclo: Aprendizaje-Seguridad-Mejorar su uso. Las cualidades prioritarias de sistemas son: Seguridad/Privacidad, Usabilidad y Confiabilidad. Se incrementa la propagación de software empaquetado COTS (Commercial-Off-The_Shelf). Crece el entendimiento de las bondades del código abierto. El desarrollo dirigido por modelos (MDD, Model Driven Development) toma fuerza. Se integra el proceso de desarrollo de software con el de sistemas. Buenos principios Cuando los cambios son frecuentes la adaptabilidad del proceso debe ser más importante que la repetición. Primero hay que considerar y satisfacer los asuntos que son de valor para el cliente. Evitar Enamorarse de tus propios lemas. Decir al cliente no lo vas a necesitar, no siempre es cierto. Prospectiva para las Décadas de 2010 y 2020 Las tendencias que van a afectar, en el futuro próximo, la forma de desarrollar software son las siguientes: Globalización. La conectividad global proporcionada por el Internet y las comunicaciones de banda ancha causará la evolución de las principales economías hacia redes de economías. En consecuencia, se requerirá de nuevos procesos de desarrollo para la colaboración global exitosa. Los retos claves serán: la colaboración multicultural, lograr las visiones compartidas y la confianza, definir mecanismos de contratación, incentivos, entregas y la sincronización de cambios, que aprovechen múltiples zonas horarias. Algunos problemas relacionados con diferencias culturales fueron identificados en un estudio sobre la adopción de procesos. Por ejemplo, SW-CMM que proviene de la cultura Individualista/Masculina/Corto plazo tuvo muy baja aceptación en la cultura de Tailandia que es Colectiva/Feminista/Largo plazo. Sistemas de sistemas. La habilidad de las organizaciones de competir, adaptarse y sobrevivir en el mercado y en la sociedad globalizada va a depender, en gran medida, su habilidad para integrar sistemas de software en sistemas de sistemas (Systems Of Systems - SOS). Un SOS integra múltiples sistemas desarrollados independientemente y se caracteriza por su gran tamaño (>10 millones de SLOCs, > 30 tipos de interfaces externas diferentes, > 20 proveedores). Los retos para el desarrollo de SOS son: lograr acuerdos a tiempo con diversos involucrados, resolver rápido los conflictos en los requerimientos y coordinar actividades de múltiples proveedores. Abundancia computacional. La Ley de Moore seguirá vigente al menos durante los próximos veinte años. Con esto, vamos a tener una abundancia de aparatos pequeños pero con gran poder de procesamiento. La Ingeniería de Software tendrá que enfrentarse con los problemas de cómo manejar el desarrollo para esta abundancia computacional, y finalmente, como integrar estos dispositivos a los SOS. Esto va a requerir de nuevos niveles de abstracción para la programación y nuevas herramientas con mayor poder basado en el uso del conocimiento. Autonomía computacional. Es una visión en la cual la Inteligencia Artificial alcanza plenamente sus objetivos. Las máquinas se vuelven autónomas, evalúan las situaciones y determinan la mejor opción para actuar. Combinación de biología y computación. Aquí habrá una influencia mutua. La computación basada en biología utiliza fenómenos moleculares o biológicos para resolver problemas computacionales. Mientras que la biología computacional tratará de mejorar las capacidades humanas, incorporando dispositivos al cuerpo humano. Este resumen lo presenté recientemente en la reunión mensual de la AMCIS, y el comentario final de una de las asistentes fue: Qué pena que todavía no hemos salido de los sesentas. Es verdad que en muchas organizaciones todavía prevalece la cultura del vaquero; pero también veo muchos esfuerzos que están cambiando este panorama. No debemos parar en el camino. Hanna Oktaba Referencia B. Boehm, A View of 20th and 21st Century Software Engineering, International Conference on Software Engineering (ICSE 06), Mayo de 2006, Shanghai, China, Copyright 2006 ACM X/06/0005. La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés principales son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS, de la cual actualmente es Secretaria. Estuvo a cargo de los proyectos MoProSoft, EvalProSoft y Pruebas Controladas, base de la actual Norma Mexicana para la Industria de Software. Actualmente es miembro de International Process Research Group (IPRC), organizado por Software Engineering Institute (SEI), cuyo objetivo es definir las líneas de investigación en el área de procesos para los próximos diez años. También es Directora Técnica del proyecto COMPE- TISOFT, cuyo objetivo es la mejora de procesos para fomentar la competitividad de pequeña y mediana industria de software en Iberoamérica. MAY-JUN

12 MEJORA CONTINUA COLUMNA Los Modelos Ágiles y no Tan Ágiles Ágil vs. CMM 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 CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek. Hace algunos meses asistí a un curso de metodologías ágiles que se impartió en la CANIETI en Monterrey. De ninguna manera me considero un experto en metodologías ágiles, y el curso en realidad era bastante básico. Una de las partes que llamó mi atención fue la mención de una aparente guerra entre los seguidores de metodologías ágiles y los seguidores de modelos como CMM o ISO De hecho, el comentario surgió para explicar el nacimiento de Ágil como respuesta por parte de aquellos que consideraban los modelos de calidad como demasiados burocráticos. En base a esto, decidí investigar un poco más y me topé, al hablar con gente dentro de la organización y algunos clientes que enfatizan este tipo de metodologías, que efectivamente se nota cierto recelo al mencionar CMM y la documentación que se requiere en un proyecto. Todo esto me sorprende porque en realidad yo no veo a estas estrategias peleadas entre sí, sino que de alguna manera podrían ser complementarias. En Esta Esquina... Antes de iniciar esta plática quiero dejar algo totalmente claro: en mi trabajo de día con día me he topado con un sinnúmero de compañías que básicamente exponen que le dan total autoridad y libertad al individuo, confían en la gente y todos los días se les asignan nuevas tareas, las cuales esperan se resuelvan en forma continua; no tienen nada documentado y por ende son fieles seguidores de metodologías ágiles. Nuevamente, bajo la premisa de que no me puedo considerar un experto en el tema, esto me parece más como caos total que como una nueva forma de hacer las cosas. Es muy fácil escudarse en manejar metodologías ágiles cuando no se está haciendo nada, ya que en sí los seguidores de metodologías ágiles defienden el que cada quien haga lo que sea más eficiente para su proyecto. Esto me llevó a la pregunta, qué son las metodologías ágiles y cómo se diferencian de la anarquía? Así que decidí investigar un poco más sobre las premisas específicas de lo que hace ágil a una metodología. A través de una rápida búsqueda en Google, fui a dar a la página del denominado Manifiesto Ágil, el cual establece las bases de las metodologías ágiles. La tabla 1 lista los principios en que se basan unos y otros. A grandes rasgos, podemos notar las siguientes diferencias: Desarrollo incremental y entregas continuas. Los agilistas defienden un desarrollo incremental y la constante entrega de valor. Esto me parece una excelente idea y no veo que esté en contra de CMM o ISO CMM habla sobre controlar los requerimientos, más no menciona nada sobre el tiempo en que se debe de recibir, por lo tanto podemos decir que modelos como CMM no entran en esto en forma tan específica. Sin embargo, si esto es viable en el proyecto que estamos desarrollando, me parece definitivamente una excelente forma de actuar, yo diría que tomemos esto como práctica. Documentación. CMM enfatiza la documentación, aunque más bien se refiere a la documentación del proceso, y no tanto del proyecto. Creo que tanto en metodologías ágiles como no ágiles debe de ser claro cómo se llevarán a cabo los proyectos y las prácticas que se aplican, desde el Planning Game hasta la programación en pares. Esto permite lograr consistencia en diferentes proyectos. Así que documentar el proceso me parece una excelente idea. Tipo de comunicación. Posiblemente, el punto más controversial es que las metodología ágiles enfatizan la comunicación cara a cara, y la comunicación entre desarrolladores y usuarios, mientras que CMM enfatiza la documentación de acuerdos. Desde mi punto de vista, podemos unir las dos ideas; creo que la mejor forma de comunicar y ponernos de acuerdo es cara a cara, y muchas veces, la mejor documentación para las decisiones que se llevan acabo en forma inmediata es la ejecución, pero en un mundo de negocios CMM Mejora continua de trabajo. Define, documenta y utiliza procesos. Compromiso de la alta dirección. Deben de existir procesos estables a través de la organización. Mide los procesos para ver si estas cumpliendo tus objetivos Controla los procesos de la organización Mejora los procesos en forma continua Manifiesto Ágil Satisfacer al cliente mediante tempranas y continuas entregas de software que le aporten valor. Aceptar cambios de requerimientos. Utilizarlos para generar ventaja competitiva para el cliente. Trabajar en conjunto entre las gente de negocios y desarrollo. Formar equipos de individuos motivados, darles el ambiente y soporte que requieren, y confiar en su capacidad para cumplir con el trabajo. La mejor forma de comunicación entre el equipo de trabajo es conversación cara a cara. El software que funciona es la mejor forma de medir el progreso. Se debe seguir un ritmo de trabajo que se pueda sostener de manera continua La atención continua a la excelencia técnica y el buen diseño fortalecen la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requerimientos y diseño surgen de equipos auto organizados. Frecuentemente y de manera regular, el equipo reflexiona sobre como puede ser más efectivo, y ajusta su comportamiento para lograrlo. 10 MAY-JUN

13 y seres humanos siempre hay riesgos, y las personas olvidan acuerdos, y a veces surgen rencores en base a estos olvidos por lo que tenemos que definir qué deberíamos de documentar y registrar solamente eso. Métricas. Otro punto fundamental en las diferencias es que CMM nos pide medir nuestros procesos, mientras que Ágil nos pide que continuamente mejoremos lo que hacemos, pero no nos pide medir nada para decidir qué mejorar. Aquí, si no tenemos salida, tenemos que tomar una decisión. Por un lado, las métricas a nivel organizacional nos ayudan para entender mejor nuestro trabajo y aprender rápidamente de nuestros errores, pero al hacer esto podría verse como falta de confianza en nuestra gente y en su capacidad para tomar decisiones racionales sobre lo que pueden mejorar. No hay una solución única, la organización debe tomar una postura. Lo único es que cualquier decisión que tomemos debe de ser apoyada por otros procesos, esto quiere decir que si vamos a medir, debe de haber toda una infraestructura de seguimiento, análisis y mejora a través de las métricas. Si no vamos a medir, debe de haber una serie de estructuras que ayuden a entrenar y transmitir el conocimiento en forma continua para así todos tener el mismo entendimiento de lo que es mejorar. Y el Ganador es: El Cliente! A donde vamos con todo esto? A final de cuentas, las ideas del manifiesto ágil son bastante interesantes; pero como todo cambio, implantarlas no es simple. De hecho, implantar el modelo ágil correctamente puede ser tan complicado como implantar ITIL, CMM o cualquier otro modelo de calidad. La organización debe tomar una decisión de hacia donde quiere moverse, para hacerlo en forma enfocada y directa y lograr el mayor beneficio hacia sus clientes. La realidad es que no deberíamos estar viendo los diferentes modelos de desarrollo de software como una gran pelea que busca a el gran ganador, sino como un grupo de herramientas con conceptos e ideas importantes que debemos de unir y extraer aquello que haga que crezcamos como organización y que a final de cuentas nos ayude a llevar el mejor producto al mercado. Al final, el ganador debe ser el cliente. Si quieres platicar más sobre el tema nos vemos en o escríbeme a lcuellar@agentesdecambio.org Luis Cuellar

14 LO QUE VIENE PRODUCTOS Atlas Licencia GoLive y Control Toolkit RedHat Adquiere JBoss RedHat Aumenta el Alcance de su Oferta Atlas, el framework de Microsoft para desarrollo de aplicaciones web ricas, ya se ve bastante maduro. De hecho, junto con el CTP (Community Technology Preview) de marzo, se anunció la disponibilidad de una licencia GoLive para Atlas. Esta licencia permite operar Atlas en sitios de producción de forma gratuita. Adicionalmente, en abril se liberó el Atlas Control Toolkit, que incluye herramientas y componentes para que los desarrolladores puedan generar controles interactivos basados en tecnología Ajax, que se conecten fácilmente con componentes.net del lado del servidor. El toolkit incluye el código fuente, documentación y ejemplos. Microsoft anunció que el código del toolkit será liberado como un proyecto de código compartido, para que la comunidad de desarrolladores pueda contribuir con mejoras y extensiones. Mayor información en atlas.asp.net Dos de las empresas más importantes en el open source quedaron unidas cuando Red Hat acordó comprar JBoss. Se espera que el acuerdo sea aprobado y se finalice en las próximas semanas. Algo que llamó la atención, es el precio acordado, de $350 millones de dólares; mas $70 millones adicionales dependiendo del desempeño de JBoss. Con esto queda demostrado el valor de las empresas open source. Con esto, Red Hat aumenta la profundidad de su stack de infraestructura de TI open source, lo cual lo pone más cerca de competir directamente con proveedores como Novell, y Microsoft. PRODUCTOS NetBeans Enterprise Pack Herramientas Open Source para Desarrollo Empresarial SQL Developer Adiós a SQL Plus Sun Microsystems anunció que abrirá como software libre, componentes clave del Java Studio Enterprise para el desarrollo de aplicaciones empresariales. Estos componentes estarán incluidos en el NetBeans Enterprise Pack, que funcionará sobre la versión 5.5 de NetBeans. Algunas de las capacidades incluidas en el NetBeans Enterprise Pack serán: Modelado bidireccional UML. Con esto se pueden generar diagramas UML que automáticamente se mantengan en sincronía con los cambios en el código fuente, y viceversa. Herramientas XML. Infraestructura para el manejo de XML y editores visuales para archivos XML. SOA y orquestación de procesos. Herramientas para desarrollar aplicaciones compuestas que funcionen dentro de arquitecturas orientadas a servicios y orquesten procesos de negocio. Esta tecnología se obtuvo gracias a la adquisición de la empresa SeeBeyond. De acuerdo con Oracle, ya es hora de que sus desarrolladores de base de datos tengan su propio IDE. Con ese propósito, la compañía liberó en marzo la versión 1.0 del SQL Developer, un ambiente gráfico para la interacción con bases de datos Oracle. Entre otras capacidades, SQL Developer permite analizar el desempeño y estructura de una base de datos desde un ambiente gráfico. Dado que está construido sobre JDeveloper, también se puede utilizar para desarrollar aplicaciones, así como para migrar otras bases de datos hacia Oracle. Oracle SQL Developer se puede descargar gratuitamente en otn.oracle.com Mayor información en 12 MAY-JUN

15

16 HERRAMIENTAS PRODUCTOS Desarrollo Guiado por Pruebas Automatización de Pruebas Unitarias Por Ariel Súcari El desarrollo guiado por pruebas (test-driven development), o TDD, es una de las principales prácticas de Extreme Programming (XP), que propone una serie de pasos para probar antes de programar (test-first programming). El proceso a realizarse es el siguiente: Se crea un caso de prueba que verifica una pequeña funcionalidad del sistema. Se ejecuta el caso de prueba, y deberá tener un resultado NO exitoso, ya que la funcionalidad que intenta probar aún no está construida. Una vez que se observa el fallo, se desarrolla únicamente el código que hará que la prueba sea exitosa. Por último, se hace un refactoring del código para asegurar que se tiene el diseño más simple para la funcionalidad que acaba de agregarse. Una vez que estos pasos son llevados a cabo, se realiza lo que motiva a la metodología: la ejecución de todas las pruebas automatizadas que se tienen construidas hasta el momento. Podemos visualizar gráficamente el párrafo anterior en el siguiente diagrama de actividad en UML. Luego de esta breve explicación que sólo intenta inducir a los desconocedores e introducir a los entendidos, se pueden vislumbrar cuáles podrían ser las ventajas y las desventajas de utilizar dicha metodología. Ventajas Requerimientos de última hora. Cuántas veces un requerimiento introducido a último momento le causó defectos en producción debido a un error en el análisis de impacto? En cuál de las siguientes situaciones preferiría estar si necesita cambiar un sistema en producción? a) Cualquiera sea el cambio que usted realice su forma de trabajo le permite probar su impacto en todo el sistema en minutos. b) Alcanza a realizar los cambios pero no tiene tiempo para probar, entonces debe liberar y cruzar los dedos para que funcione y no afecte otras partes del sistema. Se desarrollan 100% de las pruebas. Todas las pruebas se realizan de manera automática y no existe el escenario en que no se puede completar la creación de los casos de prueba debido a que no se escribe una línea de código que no corresponda a un caso de prueba automatizado. Cobertura de requerimientos al 100%. Debido a que los requerimientos son expresados en forma de casos de prueba y dichos casos son ejecutados automáticamente, cada vez que se agrega una funcionalidad al sistema, estamos seguros de que al finalizar nuestro desarrollo habremos cubierto en 100% los requerimientos del mismo, debido a que ninguno de nuestros casos de prueba ha fallado. Desventajas El éxito depende de los casos de prueba. Si se hizo una interpretación incorrecta de un requerimiento, se escribirá un caso de prueba que no satisfaga a los deseos del usuario, por lo tanto el producto final será incorrecto. Interfaces gráficas. Si se hace el intento de probar las interfaces gráficas y estas cambian, debemos perder tiempo en adaptar nuestras pruebas automatizadas. Esto podría causar que en cada versión se invierta tanto tiempo en reescribir las pruebas que se opte por no hacerlo. Complementando la Metodología Después de involucrarme un tiempo con la metodología de desarrollo guiado por pruebas y de disfrutar sus virtudes y sufrir sus defectos, he aprendido a resolver estas limitantes a través del Ariel Súcari es consultor de It Era especializado en pruebas de software. 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 7 años. 14 MAY-JUN

17 uso de un par de herramientas de IBM-Rational. A continuación les comparto más al respecto. Problema 1: Interfaces Gráficas La herramienta Functional Tester de IBM-Rational cuenta con una tecnología llamada ScriptAssure la cual utiliza algoritmos configurables para localizar a los objetos durante la ejecución de las pruebas, aunque éstos hayan cambiado desde la creación del caso de prueba inicial. Es así que Functional Tester actualiza de manera inteligente la forma en que reconoce a los objetos en Java, aplicaciones Web y.net sin intervención humana, por lo que no requiere que se actualicen los scripts cada vez que cambia la aplicación. Problema 2: El éxito Depende de los Casos de Prueba Para evitar el problema de tener casos de prueba que no concuerden con los requerimientos, lo que podemos hacer es que sean los mismos analistas de negocio quienes desarrollen los casos de prueba. Para esto, no necesitan tener conocimientos técnicos ni desarrollar scripts. Simplemente utilizan otra herramienta de IBM- Rational denominada Manual Tester, y en ella definen fácilmente los casos de prueba. Para especificar un caso de prueba, simplemente se define la serie de pasos a seguir, y se especifican valores de entrada, así como el resultado(s) esperado. Posteriormente, los desarrolladores se basan en estos casos de prueba capturados en el Manual Tester, para generar los scripts para pruebas automatizadas. Este procedimiento para generar los scripts está metodológicamente explicado y no da lugar a errores u omisiones. Algunos beneficios adicionales de capturar los casos de prueba con el Manual Tester son: Proporciona la posibilidad de colocar imágenes para complementar los pasos y contribuir a eliminar ambigüedad. Permite la reutilización de patrones de prueba en diferentes pruebas. Incluye ingreso y verificación de datos asistido durante la ejecución de las pruebas para reducir el error humano. Las herramientas que no cuenten con una tecnología semejante a la descrita, no lograrán reconocer la casilla de verificación y requerirán que el desarrollador reprograme sus pruebas. Si esto ocurre en una simple ventana de login como la del ejemplo, qué sucederá con aplicaciones complejas como en las que usted trabaja? Será tanto el trabajo de mantenimiento de los scripts de prueba que sus programadores dejarán de ser productivos. Otras virtudes que encontré en esta herramienta y que afirmaron mi decisión de adoptarla son: Los scripts de prueba se pueden programar en Visual Basic.Net y Java. Tiene herramientas de depuración incluidas en el ambiente de desarrollo tanto para VB.Net como para Java. Incluye la posibilidad de incluir pruebas manejadas por datos Soporta la introducción de expresiones regulares para el manejo de patrones. Tiene un agregado para soportar aplicaciones para terminales 3270 y Soporta pruebas automatizadas para ambientes Siebel 7.7. Conclusión Más allá de las herramientas, es importante que se entienda el concepto que está detrás de todo esto. El principal objetivo es lograr que los casos de prueba automatizados, que son la clave del éxito del desarrollo dirigido por pruebas, no partan de una mala interpretación de los requerimientos. El segundo y, no mucho menos importante, es encontrar la manera de que los programadores no dejen de ser productivos por tener que escribir casos de prueba automatizados para cada funcionalidad antes de desarrollar. Este artículo resalta estas dos cuestiones y dando un ejemplo de cómo resolverlas con un par de herramientas en particular. Pero no es necesario que se limiten a éstas. Los invito a que exploren las diferentes herramientas para pruebas automatizadas disponibles en el mercado, y tal como yo lo hice arriben a la solución técnica que más les acomode, sin perder de vista los objetivos propuestos. MAY-JUN

18 Industria Mexicana del Software Un estudio en cifras Por Dora Luz González En julio de 2005 se aplicó una encuesta a 68 gerentes de empresas del sector de la Industria del Software de México para conocer el perfil general de éstas y analizar los factores críticos de éxito del sector. Dicha encuesta forma parte de un trabajo de investigación sobre el estudio de estrategias para generar ventajas competitivas en la industria del software, realizado en la Universidad Politécnica de Valencia, España, en el programa doctoral Integración de las Tecnologías de la Información en las Organizaciones. Antes de describir el perfil de las empresas desarrolladoras de software en México, es importante destacar que los diversos análisis que hasta la fecha se han realizado con respecto al panorama de este sector no resultan aún generalizables a toda la industria, ya que cada estudio analiza sólo un subconjunto del total de empresas, por lo tanto se hace la aclaración que lo aquí se presenta son datos representativos, y no necesariamente significa que sean generalizables. Localización Geográfica de las Empresas Participantes Las empresas participantes en el estudio se localizan en 11 de los 32 estados de la República Mexicana, presentando la siguiente distribución: 2.9% Chihuahua, 1.5% en Coahuila, 44.1% en el Distrito Federal, 11.8% en Durango, 2.9% en el Estado de México, 1.5% en Guanajuato, 2.9% en Jalisco, 2.9% en Michoacán, 2.9% en Morelos, 23.5% en Nuevo León y 2.9% en Querétaro. Esta concentración es similar a la de otros estudios realizados para este sector en México [1, 2]. Número de Empresas Desarrolladoras de Software en México La respuesta a esta pregunta no tiene una cifra exacta. De acuerdo con estimaciones realizadas por ESANE consultores [2] sobre del número total de empleados y empresas de la Industria Dora Luz González Bañales es profesora del Departamento de Sistemas y Computación del Instituto Tecnológico de Durango. Actualmente se encuentra realizando su proyecto de tesis doctoral en la Universidad Politécnica de Valencia (España), en el área de análisis de estrategias competitivas en el sector de la Industria del Software de México. dogonbaa@doctor.upv.es 16 MAY-JUN

19 del Software en México, el número aproximado de empresas de la industria mexicana del software podría ser del orden de 1,500 empresas. Tamaño de las Empresas El estudio revela que el 85.29% de las empresas del sector de la Industria Mexicana del Software son de tamaño micro (54.41%) y pequeño (30.88%), el 5.8% mediana, y tan sólo el 8.82% son de tamaño grande (con un número de empleados mayor a 100). Tamaño (número de Rango Porcentaje empleados) Micro 1 a Pequeña 11 a Mediana 51 a Grande + de Tabla 1. Tamaño de empresas Número Promedio de Empleados por Tamaño de Empresa Al analizar el número promedio de empleados por tamaño de empresa, las microempresas presentan un promedio de 6 empleados, las pequeñas 23 y las medianas 76. Para el caso de las empresas grandes, se reflejó un sesgo introducido por la presencia en el estudio de una empresa de tamaño grande e intensiva en el número de personal (3,200 empleados), por lo que se estimó un valor medio corregido de empleados cuyo valor fue de 229 empleados. Antigüedad de las Empresas La Industria Mexicana del Software es una industria que se caracteriza por ser joven (47% de las empresas son menores de 7 años). La antigüedad media de las empresas que participaron en el estudio es cercana a los 9 años. Las empresas más antiguas se encuentran en el mercado desde hace 25 años (creadas partir del año 1980) y las más jóvenes son menores a un año (creadas en el año 2005). Tomando en cuenta el tiempo de permanencia en el mercado se identificaron tres bloques de antigüedad de empresas: emergentes, maduras y consolidadas (ver tabla 2). Antigüedad Emergentes 47.1 (entre 0 y 7 años) Maduras 42.6 (entre 8 y 15 años) Consolidadas 10.3 (más de 16 años) Tabla 2. Antigüedad. Porcentaje Rango de Ventas Anuales De acuerdo a los datos obtenidos en la encuesta, la mediana del rango de ventas anuales de las empresas participantes se encuentra entre 3 y 6 millones de pesos mexicanos (Tabla 3). En miles de pesos mexicanos 0 a a a a a 1, a a a a ,001 o más 16.7 Porcentaje Tabla 3. Estadísticos descriptivos de rango de ventas anuales. El 85.29% de las empresas del sector son micro o pequeñas. Utilidades La mediana del rango de utilidades de las empresas participantes en el estudio, en los últimos dos años, se encuentra entre el 6 y el 10%. Rango de utilidades Pérdidas al 5% al 10% al 15% al 20% % o más 16.4 Porcentaje Tabla 4. Estadísticos rango de utilidades en los dos últimos años. En los tres últimos años el sector de la Industria del Software de México ha registrado tasas de incremento más elevadas que el ritmo de la economía nacional. En el 2004, tuvo un crecimiento del 7%, mientras que en el 2005 este rebasó el 10% (ver Reportaje, SG Marzo-Abril 2006). Crecimiento Laboral. En lo que respecta al análisis de los datos correspondientes al crecimiento laboral, se obtuvo como resultado medio la generación de 3 nuevos empleos por año (recordando que el 85.29% de las empresas de este sector son de tamaño micro y pequeño). El 16.18% de las 68 empresas participantes manifestaron no haber tenido crecimiento laboral, MAY-JUN

20 ESPECIAL La mediana del rango de utilidades para las empresas de este sector en los últimos dos años se encuentra entre el 6 y el 10% País Salario mensual (2005) promedio en USD Filipinas $283 Turquía $438 Tailandia $510 India $570 Colombia $875 China $899 Brasil $933 Emiratos Árabes Unidos $1,508 Sudáfrica $1,558 Singapur $1,616 México $1,865 Corea $2,183 España $2,480 Bélgica $2,714 Nueva Zelanda $2,743 Australia $3,159 Canadá $3,166 Japón $3,166 Israel $3,333 Suecia $3,408 Finlandia $3,417 Holanda $3,483 Francia $3,532 Irlanda $3,532 Reino Unido $4,117 Noruega $4,178 Estados Unidos $4,416 Alemania $4,634 Hong Kong $5,055 Suiza $5,480 Tabla 5. Comparativa del salario mensual medio de un programador de software en varios países. un 27.94% un crecimiento negativo (despidos), el 52.94% haber tenido un incremento en su plantilla laboral hasta de un 8% y un 2.94% indicó tener un crecimiento laboral superior al 20%. Analizando el índice de crecimiento laboral en función del tamaño de empresas, el estudio reveló que las empresas que mayor crecimiento laboral tuvieron fueron las empresas micro (17.65%) y pequeñas (16.47%). Origen de los Ingresos Económicos En lo referente al origen de los ingresos económicos de la empresa, se presenta en primer lugar una predominancia hacia el desarrollo de software hecho a la medida (40.44%), en segundo lugar están el desarrollo de software empaquetado (16.85%) y las actividades de consultoría (14.65%). Las actividades reportadas como otras se refieren básicamente a venta, renta y mantenimiento de hardware. Y los sueldos? En la tabla 5 se muestran los salarios mensuales medios de un programador en categoría: Software Engineer / Developer / Programmer para varios países donde se puede observar una gran variación en los niveles de remuneración de esta actividad, desde un salario mensual medio de USD $283 en Filipinas, hasta un salario mensual medio de USD $5,480 en Suiza, y para el caso de México es de USD $1,865. Qué Tipo de Mercado se Cubre? Del análisis correspondiente al mercado que cubren las empresas del sector, 54.78% indicó que cubre mercados locales, 11.86% mercados regionales, 26.24% tiene cobertura nacional y 7.12% indica tener presencia internacional. Agrupando por el tamaño de empresa y por la composición de mercado que se cubre, se observa que la predominancia a cubrir mercados locales puede deberse en parte, a que la mayoría de las empresas participantes se concentran en empresas de tamaño micro, pequeña y mediana (91.17%) Y la Orientación Estratégica? Para la selección de las variables que sirvieran como base para identificar y clasificar a los grupos con base a su orientación estratégica de negocio (costo y diferenciación), se tomaron en cuenta las consideraciones teóricas de: Michael Porter, Gerry Johnson y Arthur Thomson. Para la muestra del estudio, las variables consideradas para el análisis orientación estratégica fueron: porcentaje de gasto en diseño de nuevos productos, porcentaje de gastos en mejoras en procesos, número de patentes, personal dedicado a actividades de investigación y desarrollo, porcentaje de ventas dedicado a marketing y porcentaje de productos o servicios especializados. Como resultado final para la clasificación de las empresas en función de su orientación estratégica se identificaron dos grupos: uno con 30 empresas para el grupo de estrategia por costos, y otro con 38 empresas para el grupo de estrategia por diferenciación (se aplicó la técnica estadística de análisis cluster). Conclusión En este escrito se ha presentado información obtenida a través de un estudio exploratorio aplicado al sector de la Industria del Software de México en Julio de Se han presentando los datos más significativos de este sector como lo son: antigüedad, ventas, promedio de utilidades, tamaño de empresa, orientación de negocio, generación de nuevos empleos, nivel de sueldos, mercado que se cubre y el origen de los ingresos económicos. Se espera que los datos aquí vertidos puedan servir como marco de referencia e información para todas aquellas personas, empresas e instituciones públicas y privadas que estén inmersas o tengan un interés particular en este sector. Agradecimiento especial a cada uno de los 68 gerentes de las empresas participantes en el estudio, a los representantes de PRO- SOFT, AMITI y AMCIS. Referencias 1. SE (2004), Estudio del nivel de madurez y capacidad de procesos de la industria de tecnologías de información en el área metropolitana de Monterrey, Nuevo León y el Distrito Federal y su área metropolitana Secretaría de Economía del Gobierno Mexicano. 2. ESANE, Consultores S. C. y Secretaría de Economía, México (2004), Perfil de la Industria Mexicana del Software y Servicios Relacionados Secretaría de Economía, México,Fase 1 / Criterio MAY-JUN