,etodologias agiles.pdf

8/16/2019 ,etodologias agiles.pdf

1/60

Software Guru CONOCIMIENTO EN PRÁCTICA Año 02 No.03 • Mayo-Jun io 2006 • www.softwareguru.com.m x

[ PROGRAMASprin

Noticias • Eventos • Fundamentos • Reexiones • Tecnología • Carrera

• Requerimientos

• Service Level Agreements

• Arquitectura de

Software

METODOLOGÍAS Á[ ENTREVISTA ]Carlos Montes de Oca

CIMAT

ESPECIALLa Industriaen cifras

[ UML ]Diagramasde estado


2/60


3/60


4/60


5/60

03MAY-JUN 2006www.softwareguru.com.mx

contenido may-jun 2006 Año 2 número 03

Productos

LO QUE VIENE 12Microsoft Atlas,NetBeans Enterprise Pack,Oracle SQL Developer

HERRAMIENTAS 14Desarrollo Dirigido por Pruebas

Prácticas

ADMÓN de PROVEEDORES 32Service Level Agreements, Parte 2.En la segunda parte de esta serie, Axel Nissimcomparte lineamientos y recomendaciones paradesarrollar acuerdos de nivel de servicio, desdela perspectiva del proveedor.

REQUERIMIENTOS 34El ABC de un Taller de RequerimientosMónica Vázquez nos guía a través de lo que sedebe hacer para realizar un taller de requerimien-tos exitoso.

PROGRAMACIÓN 36Desarrollo JEE Ágil con SpringDomingo Suárez nos explica algunas debilidadesde JEE, y como sobreponerlas con Spring.

ARQUITECTURA 40 Arquitectura de SoftwareLuis Felipe Martínez nos habla sobre los orígenesy trascendencia de la arquitectura de software.

UML 45Diagramas de EstadoSergio Orozco nos enseña como modelar elestado de un objeto.

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Cátedra y Más 30por Francisco Camargo

Tendencias en Software 39por Luis Daniel Soto

En Cada Número

Noticias y Eventos 04Reportaje 06Fundamentos 46Carrera 48Infraestructura 50Reexiones 54

EN PORTADA Métodos ÁgilesLo ágil es lo de hoy. Conozcamos los prin-cipios de los métodos ágiles, así como losmitos y realidades asociados a ellos.

22

Entrevista 20Carlos Montes de Oca

Industria Mexicana 16de Software en Cifras


6/60

04 www.softwareguru.com.mxMAY-JUN 2006

NOTICIAS

Noticias

Azertia México obtiene elnivel 3 CMMI

En diciembre pasado, Azertia Méxicologró la acreditación en el nivel 3 deCMMI (Capability Maturity Model Inte-grated) del Instituto de Ingeniería deSoftware (SEI) tras realizar la evalua-ción formal en sus áreas de proyectoscerrados (soluciones) y fábrica de soft-ware, que se encuentra en Cuautitlán,Estado de México.

Con esta evaluación, Azertia se convir-tió en la segunda empresa en Méxicoen obtener este nivel de CMMI, lo cualpone de manifiesto la capacidad técni-ca, de gestión y de calidad que poseeen el desarrollo y mantenimiento deaplicaciones de software, tanto en lalínea de proyectos cerrados como en lafábrica de software.

Azertia es una compañía multinacionaloriginaria de España y pertenecien-te a Corporación IBV (BBVA e Iber-drola), dedicada a ofrecer serviciosde TI. Cuenta con centros de trabajoen diversas localidades de Españay Latinoamérica.

Mayor información enwww.azertia.com.mx

Magnabyte alcanza nivel 2 de norma mexicana basada en MoProSoft

Después de un proceso de implantación del modelo MoProSoft y un seguimientointerno, Magnabyte se convirtió en la primera empresa dictaminada por NYCE bajo enivel 2 de la norma mexicana aplicable para la verificación de procesos de Tecnologíasde Información NMX-I-059/02. Dicha norma está basada en el modelo MoProSoftque busca llevar a las empresas mexicanas a alcanzar niveles internaciones en capa-cidad de procesos, y mide el nivel de madurez de 9 procesos que corresponden a lascapas de Alta Dirección, Gestión y Operación.

“El participar en este modelo resultaba indispensable para nosotros, ya que creemosfirmemente 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 laSecretaría de Economía, el cual se alinea a nuestros objetivos de negocio, como con-vertirnos en una empresa líder latinoamericana en la industria de software, desarrollarsoluciones de alta competitividad y generar empleos para profesionistas mexicanos”,indicó Oscar Flores, Director General de Magnabyte.

Mayor información enwww.magnabyte.com.mx

Gartner EnterpriseIntegration Summit

El pasado 5 y 6 de abril, Gartner realizó en la Ciudad deMéxico su Enterprise Integration Summit, donde se mane-jaron temas sobre de Integración de Aplicaciones, ServiciosWeb, SOA y BPM. Los analistas de Gartner compartieronsu análisis del mercado, las principales tendencias, y lec-ciones aprendidas, e hicieron diversas recomendacionespara las organizaciones involucradas o prontas a iniciarproyectos de este tipo. Entre las empresas patrocinado-ras estuvieron Sterling Commerce, IBM, Oracle, Microsoft,Software AG, Axxis, y otras más.

En comparación con la cumbre de Gartner del año anteriorrelacionada con los mismos temas, este año percibimos quelos asistentes ya tenían una mucho mejor idea de temascomo BPM y SOA, y en varios casos ya tenían en curso inicia-tivas de este tipo. Adicionalmente, los proveedores tambiénreflejaron una mayor madurez en cuanto a su oferta.

SigmaTao ya es CMMI 3

Otra empresa que recientemente logró su acreditación en el nivel 3 de CMMI es SigTao Factory, fábrica de software mexicana ubicada en Querétaro.

Esta evaluación de reconocimiento internacional, se suma a las anteriormente obtendas (CMM-5 y Java Center of Excellence) y ubica a Sigma Tao en el mercado mexcomo parte del selecto grupo que ha obtenido este grado de evaluación, a la vez quconfirma su compromiso con la calidad y excelencia en sus productos, así como en procesos de ingeniería software que los generan. SigmaTao tiene actualmente 540 Igenieros altamente capacitados y que proveen servicios a las más grandes empresasinstituciones del pais. SigmaTao es parte de EIDON Software, corporativo que incla Zentrum (Cmm-3), Blitz (Cmm-3) y ASPEL (Cmm-2) teniendo en total más deprofesionales dedicados al desarrollo de soluciones de software de alta calidad.


7/60

05www.softwareguru.com.mx MAY-JUN 2006

Eventos

13 Mayo 2006Debian Day Centro Vacacional IMSS. Oaxtepec, Mor.

es.debconf.org/debianday

14 y 21 Mayo 2006DebConf6Centro Vacacional IMSS. Oaxtepec, Mor.debconf6.debconf.org

16 y 17 Mayo 20068va Conferencia Anual Information SecurityHotel Camino Real, Ciudad de MéxicoTel: (55) 5340 23 22www.informationsecurity.com.mx

22-24 Mayo 2006Congreso de Software Libre GULEV 2006Museo del Transporte. Xalapa, Veracruzwww.gulev.org.mx

25 Mayo 2006IDC Service Oriented Architecture SeminarHotel Presidente Intercontinental Monterrey, NLTel: (55) 5661 – 3791www.idc-eventos.com/soa06

25 y 26 Mayo 2006Optimizando los servicios de TI con ITIL eISO 20000 y Automatizando la administra-ción de TI con ITSM25 de Mayo - Ciudad de México, 26 de Mayo - Monterrey, NLTel: (55) 5281 76 70www.itera.com.mx

5 de Junio 2006IDC IT Security & Business Continuity Con-ference 2006Centro Banamex, Ciudad de MéxicoTel: (55) 5661 – 3791www.idc-eventos.com

9 de JunioTCDS BPM Executive Day 2006Ciudad de MéxicoTel: (55) 5639-3742www.tcds.com.mx/mx/events/bpmxd06.html

27 y 28 de Junio 2006Gartner 2nd Annual Outsourcing SummitCentro Banamex, Ciudad de MéxicoTel: (55) 5584 9370www.gartner.com/mx/outsourcing

Fox inauguró elCentro de Tecnología ElectrónicaVehicular del ITESO El pasado 9 de marzo el presidente de México, Vicente Foxinauguró en el ITESO, Universidad Jesuita de Guadalajara, elCentro de Tecnología Electrónica Vehicular (CTEV). El obje-tivo de este proyecto es establecer un centro donde concu-rran los sectores automotriz, electrónico y de software, para

diseñar, desarrollar y probar sistemaspara automóviles.

“Lo que estamos tratando de hacer aquíes vincular a tres sectores muy impor-tantes para México, nada menos que laelectrónica y automotriz, con la que yoconsidero la más estratégica, que es tec-nologías de información y comunicacio-nes” mencionó Eduardo Ramírez, Directorde Soluciones Tecnológicas, la empresamexicana con la cual el ITESO firmó elconvenio que originó este proyecto.

El centro está ubicado dentro del edificio de Tecnologías deInformación del ITESO, en un espacio de 425 metros cuadra-dos. Se creó con una inversión de cinco millones de pesos,de los cuales el 25 por ciento corrió a cargo del Gobierno fe-deral, a través del fondo ProSoft, otro 25 por ciento lo aportóel Gobierno Estatal, a través del Consejo Estatal de Ciencia yTecnología de Jalisco (Coecytjal), y el 50 por ciento restantefue aportado por el ITESO y Soluciones Tecnológicas.


8/60

La principal estrategia de IT@baja es promo-ver proyectos que permitan impulsar el cre-cimiento de las empresas ya instituidas, y lacreación de nuevas, para fomentar una altacompetitividad en el estado que lleve even-tualmente a un grado de excelencia a los dis-tintos proveedores de servicios y productosde TI, lo que consolidará al estado como unaalternativa real para empresas norteamerica-nas en busca de soluciones integrales.

Aprovechando la proximidad con los EstadosUnidos, y el huso horario compartido con Ca-lifornia, este Cluster ofrece gente y empresasque conocen perfectamente la cultura de nego-cios e incluso laboral de las compañías estado-unidenses, además de que dominan el idiomainglés, lo que representa una ventaja definitivapara ganar la preferencia de las empresas quebuscan una alternativa viable en término decostos y valor agregado, sin sacrificar calidad.

Antecedentes y FuncionesA finales del 2002, como resultado de un es-tudio para definir las competencias del estadode Baja California. se establecieron los esque-mas, conformación y estrategia del Cluster ne-cesarias para dirigir el desarrollo del sector detecnologías de información en este estado. Enuna etapa inicial, se optó por concentrarse enel desarrollo de software y promoción de lasaplicaciones existentes en el estado.

Entre las funciones de IT@Baja están:• Ejecutar las estrategias de promoción, ca-pacitación, certificación, vinculación, legal,fondeo, etc.• Promover la integración continua de las em-presas de este ramo a través de los organis-mos que las representan.• Promover proyectos de subcontratación dedesarrollo de software.• Buscar el entrenamiento y capacitacióncontinua de sus integrantes.• Estandarizar la aplicación de metodologías

entre sus integrantes.• Vinculación con organismos similares enMéxico y otras regiones, principalmente enel Estado de California, en donde existe unademanda muy importante de subcontrata-ción de desarrollo de software.• Vigilar la imparcialidad de asignación deoportunidades de negocio y proyectos inter-nos mediante el código de ética y estatutosdel cluster.• Conceder el uso de la marca a empresas quetengan la certificación de calidad.• Proveer un espacio físico para reunionesestratégicas.• Promover la innovación e incubación de ne-gocios, a través de centros de desarrollo detecnologías de información.

Logros y MetasDentro de los principales logros a la fecha,IT@baja ha promovido continuamente la in-teracción de las compañías integrantes delCluster, conformando varias asociaciones,programas y comunidades. He aquí algunosejemplos:• Asociación de Profesionales de IT.• Centro de Excelencia Tecnológica en Están-dares Abiertos.• Comisión Académica e Industria.• Modelo de Desarrollo CT Connect.• Comunidad .Net.

A la fecha, IT@Baja cuenta con 43 socios ac-tivos, que reunen una facturación superiora los 28 millones de dólares en 2005. Estorepresenta más del 60% de la facturación delas empresas de software en Baja California.

Dentro de los planes de vinculación académica,se creó un programa de capacitación y certifica-ción de maestros universitarios en tecnología.NET y Java, además de impartir un taller deMoProSoft y un diplomado de Pruebas de Soft-ware. Se formalizó un convenio de colaboracióncon la Universidad Autónoma de Baja California

(UABC), con el que se pretende lograr un prgrama de extensión académica y conformar unaplan 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 reginal, nacional e internacional.• Promover el soporte gubernamental aorganizaciones.• Soporte y alineación de intereses con el sec-tor académico.• Incrementar la membresía.• Desarrollar comisiones internas.• Desarrollar talleres internos y externos.• Atraer socios de clase mundial.• Actualizar y promover proyectos y programaa partir de iniciativas de sus integrantes.• Atraer nuevas inversiones y fondos hacia edesarrollo de TI en el Estado.

Las EmpresasLa asociación está constituida por distin-tos representantes que tienen algún tipode relación con el sector de tecnologías deinformación de Baja California; empresade desarrollo de soluciones a la medida,proveedores de soluciones contables, ad-ministrativas, de recursos humanos, de co-mercio exterior, ERPs, etc., proveedores dsoftware a la medida y de infraestructuratecnológica.

Los integrantes hasta la fecha son: GrupoRed, Nettss, Prisma Computación, GrupSyS, Coordenada, SITSA, Telecomm, Evest, G-H & T, BTS, RT Solutions, SmartBCybercorp, Betta Global Systems, LIDSA, Aprovi, GM Consultores, , TecnologEducativa, EYS, Condete, Infosyst S.CIntelligence Learning, Imacor, Aster, Intefase Mircrosystems, Arkus, Gr SolucioneGrupo Tress, Zentrum, Nexus, INTEGRBusiness Ware, Gr Soluciones Computacionales, Condete, Central Software y 4 Integradoras: INTUARE, SDS,iMedis e INTA

06 MAY-JUN 2006 www.softwareguru.com.mx

CLUSTERS

IT@BajaUna Solución IntegralEsta asociación civil sin fin de lucro, formada hace cinco años y constituida en lasegunda mitad del 2004, busca explotar las ventajas de su ubicación geográfica yconstituir al estado de Baja California en un Cluster líder en México en el desarrollode empresas de TI, para fomentar la exportación de servicios, principalmente al ve-cino país del norte.

Asamblea en Mexicali, Marzo 2006


9/60


10/60

P ara cuando lean esta columna, probablemente ya se habrá llevado acabo la International Conference on Software Engineering (ICSE’06)en Shanghai, donde Barry Boehm participará como conferencista, yen su plática presentará su visión de la perspectiva histórica y el futuro de laIngeniería de Software. Así que conociendo la importancia de este personajey el impacto de sus opiniones, les comparto un pequeño resumen del artículoque Boehm desarrolló para esta ocasión y que nos hizo llegar a los miembrosdel 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 softwarede 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 propiedadesde software útiles para el cliente. Esto nos habla de calidad del software, perono desde una perspectiva de actividades —como otras definiciones—, sino delvalor generado para el cliente. Posteriormente, el artículo hace una retrospec-tiva sobre la ingeniería de software desde los años cincuenta hasta la épocaactual, y termina con predicciones para el próximo par de décadas. Veamosentonces los puntos más significativos:

Años CincuentaSe aplica al desarrollo de software el mismo proceso que al desarrollo de hard-ware, tipo cascada rigurosa. Las lecciones aprendidas fueron las siguientes:Buenos principios• No ignorar matemáticas, ciencias de la computación, sociales, económicasy 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 proyectoEvitar • Seguir demasiado rigurosamente el proceso de desarrollo secuencial.

SesentasEl 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 proce-so de desarrollo tipo “codifica y corrige” (code and fix). Se inició la cultura delhacker en el buen sentido de la palabra, es decir experto en programación, y ladel vaquero (cowboy) que hace desarrollos heroicos de última hora.Buenos principios• Atreverse a hacer prototipos novedosos, no limitarse a repetir lo que yase conoce.• Respetar que el software es diferente. No se puede incrementar la velocidad desu desarrollo de manera infinita.Evitar • Programación al estilo vaquero. Parches de último minuto o trabajo de últimanoche pueden traer graves consecuencias.

SetentasSe identifican las diferentes fases del desarrollo: requerimientos, análisis,diseño, codificación y pruebas. Se introduce la programación estructuraday métodos formales para especificar software. Se identifican principios dediseño, como modularidad, encapsulación, abstracción de tipos de datos,

08 www.softwareguru.com.mxwww.softwareguru.com.mxMAY-JUN 2006

acoplamiento débil y alta cohesión, entre otros. Se publica el modelo de cascada y se definen los conceptos dverificació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 paratener una visión compartida con el cliente.Evitar • Desarrollo descendente (top-down) a toda costa. Lorequerimientos emergentes y los cambios lo hacen pocorealista, para la mayoría de los casos.

OchentasSe busca la productividad y escalabilidad de sistemas equipos de desarrollo. La Orientación a Objetos renaccon 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 primerestándares. Nace el concepto de Fábricas de Software yse generan las primeras herramientas para incrementar laproductividad a través de la programación por el usuariotales como 4GLs.Buenos principios• Hay muchos caminos para incrementar la productividaque 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 bulletque aplica a toda clase de problemas.

NoventasLa concurrencia (paralelismo y distribución) adquiere myor importancia con respecto a procesos secuenciales. LOrientación a Objetos se extiende a las fases de análisis diseño. Se acuerda un lenguaje de modelado (UML) y genera el primer proceso comercial de desarrollo orientado a objetos (RUP). Los diseñadores y los arquitectos dsoftware empiezan a recaudar las mejores experiencias através de patrones de diseño y de arquitectura. Se defineel Modelo Espiral para el desarrollo basado en el análiside riesgos y su vertiente conocida como desarrollo iteratvo e incremental. El Software Libre toma fuerza y se crelos primeros ejemplos exitosos. La usabilidad de sistemase convierte en el foco de atención e investigación. Sofware empieza a ocupar la posición crítica en el mercadcompetitivo y en la sociedad (web).Buenos principios• El tiempo es dinero. La gente invierte en software esperandretorno de inversión, mientras más rápido se desarrolle el soft

C O L U M N A

Historia y Futuro de la Ingeniería de SoftwareVisión de Barry Boehm

TEJIENDO NUESTRA RED


11/60

La Dra. HannaOktaba es profesora de la UNAM anivel licenciatura yposgrado. Sus áreasde interés principalesson Ingeniería deSoftware, TecnologíaOrientada a Objetos,Modelos de Procesosde Software y Mejorade Procesos. Es fun- dadora de la AMCIS,de la cual actualmente es Secretaria.Estuvo a cargo de losproyectos MoProSoft,EvalProSoft y PruebasControladas, basede la actual NormaMexicana para laIndustria de Software.Actualmente es miembro de InternationalProcess ResearchGroup (IPRC), orga- nizado por SoftwareEngineering Institute(SEI), cuyo objetivoes definir las líneasde investigación enel área de procesospara los próximosdiez años. Tambiénes Directora Técnicadel proyecto COMPE- TISOFT, cuyo objetivoes la mejora de procesos para fomentarla competitividad depequeña y medianaindustria de softwareen Iberoamérica.


ware, más rápido se recupera la inversión, pero eso pasa sóloen el caso cuando la calidad de software es satisfactoria.• El software tiene que ser útil para la gente, es la partecrucial de la definición de Ingeniería.Evitar • Hacer las cosas demasiado rápido. Los hitos muy ambi-ciosos a menudo traen como consecuencia las especifica-ciones incompletas, que resultan en mucho re-trabajo.

Situación ActualLos temas nuevos son la agilidad en el desarrollo y el va-lor para el cliente. Se redacta el Manifiesto de Agilidaden respuesta al estilo promovido por CMM. Surgen nue-vos dispositivos (PDAs, celulares) que involucran el ciclo:Aprendizaje-Seguridad-Mejorar su uso. Las cualidadesprioritarias de sistemas son: Seguridad/Privacidad, Usa-bilidad y Confiabilidad. Se incrementa la propagación desoftware empaquetado COTS (Commercial-Off-The_Shelf).Crece el entendimiento de las bondades del código abier-to. El desarrollo dirigido por modelos (MDD, Model DrivenDevelopment) toma fuerza. Se integra el proceso de desa-rrollo de software con el de sistemas.Buenos principios• Cuando los cambios son frecuentes la adaptabilidad delproceso debe ser más importante que la repetición.• Primero hay que considerar y satisfacer los asuntos queson de valor para el cliente.Evitar • Enamorarse de tus propios lemas. Decir al cliente “no lovas a necesitar”, no siempre es cierto.

Prospectiva para las Décadasde 2010 y 2020Las tendencias que van a afectar, en el futuro próximo, la for-ma de desarrollar software son las siguientes:Globalización. La conectividad global proporcionada por elInternet y las comunicaciones de banda ancha causará laevolución de las principales economías hacia redes de eco-nomías. En consecuencia, se requerirá de nuevos procesosde desarrollo para la colaboración global exitosa. Los retosclaves serán: la colaboración multicultural, lograr las visionescompartidas y la confianza, definir mecanismos de contrata-ción, incentivos, entregas y la sincronización de cambios, queaprovechen múltiples zonas horarias. Algunos problemasrelacionados con diferencias culturales fueron identificadosen un estudio sobre la adopción de procesos. Por ejemplo,SW-CMM que proviene de la cultura Individualista/Mascu-lina/Corto plazo tuvo muy baja aceptación en la cultura deTailandia que es Colectiva/Feminista/Largo plazo.

Sistemas de sistemas. La habilidad de las organizacionesde competir, adaptarse y sobrevivir en el mercado y en la

sociedad globalizada va a depender, en gran medida, suhabilidad para integrar sistemas de software en sistemasde sistemas (Systems Of Systems - SOS). Un SOS integramúltiples sistemas desarrollados independientemente yse caracteriza por su gran tamaño ( > 10 millones de SLOCs,> 30 tipos de interfaces externas diferentes,> 20 provee-dores). Los retos para el desarrollo de SOS son: lograracuerdos a tiempo con diversos involucrados, resolverrápido los conflictos en los requerimientos y coordinar ac-tividades de múltiples proveedores.

Abundancia computacional. La Ley de Moore seguirá vi-gente al menos durante los próximos veinte años. Conesto, vamos a tener una abundancia de aparatos peque-ños pero con gran poder de procesamiento. La Ingenieríade Software tendrá que enfrentarse con los problemas decómo manejar el desarrollo para esta abundancia compu-tacional, y finalmente, como integrar estos dispositivos alos SOS. Esto va a requerir de nuevos niveles de abstrac-ción para la programación y nuevas herramientas con ma-yor poder basado en el uso del conocimiento.

Autonomía computacional. Es una visión en la cual la In-teligencia Artificial alcanza plenamente sus objetivos. Lasmáquinas se vuelven autónomas, evalúan las situacionesy determinan la mejor opción para actuar.

Combinación de biología y computación. Aquí habrá unainfluencia mutua. La computación basada en biología uti-liza fenómenos moleculares o biológicos para resolverproblemas computacionales. Mientras que la biologíacomputacional tratará de mejorar las capacidades huma-nas, incorporando dispositivos al cuerpo humano.

Este resumen lo presenté recientemente en la re-unión mensual de la AMCIS, y el comentario final deuna de las asistentes fue: “Qué pena que todavíano hemos salido de los sesentas”. Es verdad que enmuchas organizaciones todavía prevalece la culturadel vaquero; pero también veo muchos esfuerzosque están cambiando este panorama. No debemosparar en el camino.

—Hanna Oktaba

Referencia• B. Boehm, “A View of 20th and 21st Century SoftwareEngineering, International Conference on Software Engi-neering (ICSE’06), 20-28 Mayo de 2006, Shanghai, China,Copyright 2006 ACM 1-59593-085-X/06/0005.


12/60

H ace 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 me-todologías ágiles, y el curso en realidad era bastante básico.Una de las partes que llamó mi atención fue la mención deuna aparente guerra entre los seguidores de metodologíaságiles y los seguidores de modelos como CMM o ISO 9000.De hecho, el comentario surgió para explicar el nacimientode Ágil como respuesta por parte de aquellos que considera-ban los modelos de calidad como demasiados burocráticos.En base a esto, decidí investigar un poco más y me topé, alhablar con gente dentro de la organización y algunos clientesque enfatizan este tipo de metodologías, que efectivamentese nota cierto recelo al mencionar CMM y la documentaciónque se requiere en un proyecto. Todo esto me sorprende por-que en realidad yo no veo a estas estrategias peleadas entresí, sino que de alguna manera podrían ser complementarias.

En Esta Esquina...Antes de iniciar esta plática quiero dejar algo totalmente cla-ro: en mi trabajo de día con día me he topado con un sinnúme-ro de compañías que básicamente exponen que le dan totalautoridad y libertad al individuo, confían en la gente y todoslos días se les asignan nuevas tareas, las cuales esperan seresuelvan en forma continua; no tienen nada documentado ypor ende son fieles seguidores de metodologías ágiles. Nue-vamente, bajo la premisa de que no me puedo considerar unexperto en el tema, esto me parece más como caos total quecomo una nueva forma de hacer las cosas.

Es muy fácil escudarse en manejar metodologías ágilescuando no se está haciendo nada, ya que en sí los segui-dores de metodologías ágiles defienden el que cada quienhaga lo que sea más eficiente para su proyecto. Esto me lle-vó a la pregunta, ¿qué son las metodologías ágiles y cómose diferencian de la anarquía? Así que decidí investigar un

poco más sobre las premisas específicas de lo que hace ágia una metodología. A través de una rápida búsqueda en Google, fui a dar a la página del denominado “Manifiesto Ágiel cual establece las bases de las metodologías ágiles. Latabla 1 lista los principios en que se basan unos y otros.

A grandes rasgos, podemos notar las siguientes diferenciasDesarrollo incremental y entregas continuas. Los agilistasdefienden un desarrollo incremental y la constante entregade valor. Esto me parece una excelente idea y no veo que esten contra de CMM o ISO 9000. CMM habla sobre controlarequerimientos, más no menciona nada sobre el tiempo enque se debe de recibir, por lo tanto podemos decir que modelos como CMM no entran en esto en forma tan específica. Sembargo, si esto es viable en el proyecto que estamos desarrollando, me parece definitivamente una excelente forma dactuar, yo diría que tomemos esto como práctica.

Documentación. CMM enfatiza la documentación, aunqumás bien se refiere a la documentación del proceso, y ntanto del proyecto. Creo que tanto en metodologías ágilecomo no ágiles debe de ser claro cómo se llevarán a cablos proyectos y las prácticas que se aplican, desde el “Planning Game” hasta la programación en pares. Esto permitlograr consistencia en diferentes proyectos. Así que documentar el proceso me parece una excelente idea.

Tipo de comunicación. Posiblemente, el punto más contro-versial es que las metodología ágiles enfatizan la comunicación cara a cara, y la comunicación entre desarrolladores usuarios, mientras que CMM enfatiza la documentación dacuerdos. Desde mi punto de vista, podemos unir las doideas; creo que la mejor forma de comunicar y ponernode acuerdo es cara a cara, y muchas veces, la mejor documentación para las decisiones que se llevan acabo en forminmediata es la ejecución, pero en un mundo de negocio

C O L U M N A

10 www.softwareguru.com.mx

Los Modelos Ágiles y no Tan ÁgilesÁgil vs. CMM

MEJORA CONTINUA

Luis R. Cuellar esDirector de Calidada nivel mundial deSofttek InformationServices. Luis esreconocido por laAmerican Society forQuality (ASQ) comoCertied QualityManager, CertiedSoftware Engineer, ySix Sigma Black Belt.En los últimos cincoaños ha estado acargo de la denicióne implantación de la

estrategia para CMM5y Six Sigma a travésde las diferentesáreas del centro dedesarrollo de Softtek.

MAY-JUN 2006

CMM• Mejora continua de trabajo.• Define, documenta y utiliza procesos.• Compromiso de la alta dirección.• Deben de existir procesos estables a tra-vés de la organización.• Mide los procesos para ver si estas cum-pliendo 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 confiaren 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.


13/60

y seres humanos siempre hay riesgos, y laspersonas olvidan acuerdos, y a veces surgenrencores en base a estos olvidos por lo quetenemos que definir qué deberíamos de do-cumentar y registrar solamente eso.

Métricas. Otro punto fundamental en las dife-rencias es que CMM nos pide medir nuestrosprocesos, mientras que Ágil nos pide que con-tinuamente mejoremos lo que hacemos, perono nos pide medir nada para decidir qué me-jorar. Aquí, si no tenemos salida, tenemos quetomar una decisión. Por un lado, las métricas anivel organizacional nos ayudan para entendermejor nuestro trabajo y aprender rápidamentede nuestros errores, pero al hacer esto podríaverse como falta de confianza en nuestra gentey en su capacidad para tomar decisiones racio-nales sobre lo que pueden mejorar. No hay unasolución única, la organización debe tomar

una postura. Lo único es que cualquier deci-sión que tomemos debe de ser apoyada porotros procesos, esto quiere decir que si vamosa medir, debe de haber toda una infraestructu-ra de seguimiento, análisis y mejora a travésde las métricas. Si no vamos a medir, debe dehaber una serie de estructuras que ayuden aentrenar y transmitir el conocimiento en formacontinua para así todos tener el mismo enten-dimiento de lo que es mejorar.

Y el Ganador es: ¡El Cliente!¿A donde vamos con todo esto? A final decuentas, las ideas del manifiesto ágil sonbastante interesantes; pero como todo cam-bio, implantarlas no es simple. De hecho,implantar el modelo ágil correctamente pue-de ser tan complicado como implantar ITIL,CMM o cualquier otro modelo de calidad. Laorganización debe tomar una decisión de ha-

cia donde quiere moverse, para hacerlo enforma enfocada y directa y lograr el mayobeneficio hacia sus clientes.

La realidad es que no deberíamos estar vien-do los diferentes modelos de desarrollo desoftware como una gran pelea que busca a elgran ganador, sino como un grupo de herra-mientas con conceptos e ideas importantesque debemos de unir y extraer aquello quehaga que crezcamos como organización yque a final de cuentas nos ayude a llevar elmejor producto al mercado. Al final, el ganador debe ser el cliente.

Si quieres platicar más sobre el tema nos ve-mos en www.agentesdecambio.org o escríbe-me [email protected]

—Luis Cuellar


14/60

P R O D U C T O S

PRODUCTOS

SQL DeveloperAdiós a SQL Plus

De acuerdo con Oracle, ya es hora de que sus desarro-lladores de base de datos tengan su propio IDE. Con esepropósito, la compañía liberó en marzo la versión 1.0 delSQL Developer, un ambiente gráfico para la interaccióncon bases de datos Oracle. Entre otras capacidades, SQLDeveloper permite analizar el desempeño y estructura deuna base de datos desde un ambiente gráfico. Dado queestá construido sobre JDeveloper, también se puede uti-lizar para desarrollar aplicaciones, así como para migrarotras bases de datos hacia Oracle.

Oracle SQL Developer se puede descargar gratuitamenteen otn.oracle.com

LO QUE VIENE

NetBeans Enterprise Pack Herramientas Open Source para Desarrollo Empresarial

Sun Microsystems anunció que abrirá como software libre, componen-tes clave del Java Studio Enterprise para el desarrollo de aplicacionesempresariales. Estos componentes estarán incluidos en el NetBeansEnterprise Pack, que funcionará sobre la versión 5.5 de NetBeans.

Algunas de las capacidades incluidas en el NetBeans EnterprisePack serán:Modelado bidireccional UML. Con esto se pueden generar diagra-mas UML que automáticamente se mantengan en sincronía con loscambios en el código fuente, y viceversa.Herramientas XML. Infraestructura para el manejo de XML y editoresvisuales para archivos XML.SOA y orquestación de procesos. Herramientas para desarrollar apli-caciones compuestas que funcionen dentro de arquitecturas orien-tadas a servicios y orquesten procesos de negocio. Esta tecnologíase obtuvo gracias a la adquisición de la empresa SeeBeyond.

Mayor información enwww.netbeans.org

Atlas, el framework de Microsoft para desarrollo de aplicaciones web “ricas”, yase ve bastante maduro. De hecho, junto con el CTP ( Community Technology Pre-view ) 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 herra-mientas y componentes para que los desarrolladores puedan generar controlesinteractivos basados en tecnología Ajax, que se conecten fácilmente con compo-nentes .Net del lado del servidor. El toolkit incluye el código fuente, documenta-ción y ejemplos. Microsoft anunció que el código del toolkit será liberado comoun proyecto de código compartido, para que la comunidad de desarrolladorespueda contribuir con mejoras y extensiones.

Mayor información enatlas.asp.net

AtlasLicencia GoLive y Control Toolkit

RedHat Adquiere JBossRedHat Aumenta el Alcance de su Oferta

Dos de las empresas más importan-tes en el open source quedaron unidascuando Red Hat acordó comprar JBoss.Se espera que el acuerdo sea aprobadoy se finalice en las próximas semanas.Algo que llamó la atención, es el precioacordado, de $350 millones de dólares;mas $70 millones adicionales depen-diendo del desempeño de JBoss. Conesto queda demostrado el valor de lasempresas open source.

Con esto, Red Hat aumenta la profundi-dad de su “stack” de infraestructura deTI open source, lo cual lo pone más cercade competir directamente con proveedo-res como Novell, y Microsoft.



15/60


16/60

P R O D U C T O S

Desarrollo Guiado por PruebasAutomatización de Pruebas UnitariasPor Ariel Súcari

E l desarrollo guiado por pruebas ( test-driven development ), oTDD, es una de las principales prácticas deExtreme Program-ming (XP), que propone una serie de pasos para probar antesde programar ( test-first programming ).

El proceso a realizarse es el siguiente:• Se crea un caso de prueba que verifica una pequeña funcionalidaddel 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ódigoque hará que la prueba sea exitosa.• Por último, se hace unrefactoring del código para asegurar que se tie-ne 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 mo-tiva a la metodología: la ejecución de todas las pruebas automatiza-das que se tienen construidas hasta el momento.

Podemos visualizar gráficamente el párrafo anterior en el siguientediagrama de actividad en UML.

Luego de esta breve explicación que sólo intenta inducir a lodesconocedores e introducir a los entendidos, se pueden vislumbrar cuáles podrían ser las ventajas y las desventajas de utilizadicha metodología.

Ventajas• Requerimientos de última hora. ¿Cuántas veces un requerimiento in-troducido a último momento le causó defectos en producción debidoun error en el análisis de impacto? ¿En cuál de las siguientes situacionpreferiría estar si necesita cambiar un sistema en producción?a) Cualquiera sea el cambio que usted realice su forma de trabajo permite probar su impacto en todo el sistema en minutos.b) Alcanza a realizar los cambios pero no tiene tiempo para probaentonces debe liberar y cruzar los dedos para que funcione y no afete otras partes del sistema.

• Se desarrollan 100% de las pruebas. Todas las pruebas se rea-lizan de manera automática y no existe el escenario en que no spuede completar la creación de los casos de prueba debido a queno se escribe una línea de código que no corresponda a un caso dprueba automatizado.

• Cobertura de requerimientos al 100%. Debido a que los reque-rimientos son expresados en forma de casos de prueba y dichocasos son ejecutados automáticamente, cada vez que se agregauna funcionalidad al sistema, estamos seguros de que al finalizar nuestro desarrollo habremos cubierto en 100% los requermientos del mismo, debido a que ninguno de nuestros casos dprueba ha fallado.

Desventajas• El éxito depende de los casos de prueba. Si se hizo una inter-pretación incorrecta de un requerimiento, se escribirá un caso dprueba que no satisfaga a los deseos del usuario, por lo tanto elproducto final será incorrecto.

• Interfaces gráficas. Si se hace el intento de probar las interfa-ces gráficas y estas cambian, debemos perder tiempo en adaptanuestras pruebas automatizadas. Esto podría causar que en cadaversión se invierta tanto tiempo en reescribir las pruebas que sopte por no hacerlo. Complementando la MetodologíaDespués de involucrarme un tiempo con la metodología de dsarrollo guiado por pruebas y de disfrutar sus virtudes y sufrsus defectos, he aprendido a resolver estas limitantes a través de

HERRAMIENTAS

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 coor- dinado proyectos de la disciplina de pruebas en Inglaterra, Estados Unidos, Venezuela, Argentina y México durante los últimos 7 años.



17/60

uso de un par de herramientas de IBM-Rational. A continuaciónles comparto más al respecto.

Problema 1: Interfaces GráficasLa herramienta Functional Tester de IBM-Rational cuenta conuna tecnología llamada ScriptAssure la cual utiliza algoritmosconfigurables para localizar a los objetos durante la ejecuciónde las pruebas, aunque éstos hayan cambiado desde la creacióndel caso de prueba inicial. Es así que Functional Tester actualizade manera inteligente la forma en que reconoce a los objetosen Java, aplicaciones Web y .NET sin intervención humana, porlo que no requiere que se actualicen los scripts cada vez quecambia la aplicación.

Las herramientas que no cuenten con una tecnología semejante ala descrita, no lograrán reconocer la casilla de verificación y reque-rirán que el desarrollador reprograme sus pruebas. Si esto ocurreen 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 susprogramadores dejarán de ser productivos.

Otras virtudes que encontré en esta herramienta y que afirmaronmi 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 dedesarrollo 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 manejode patrones.• Tiene un agregado para soportar aplicaciones para terminales3270 y 5250.• Soporta pruebas automatizadas para ambientes Siebel 7.7.

Problema 2: El éxito Depende de los Casos dePruebaPara evitar el problema de tener casos de prueba que no concuerden con los requerimientos, lo que podemos hacer es que seanlos mismos analistas de negocio quienes desarrollen los casos deprueba. Para esto, no necesitan tener conocimientos técnicos ndesarrollar scripts. Simplemente utilizan otra herramienta de IBMRational denominada Manual Tester, y en ella definen fácilmenlos casos de prueba.

Para especificar un caso de prueba, simplemente se define la seride pasos a seguir, y se especifican valores de entrada, así como eresultado(s) esperado. Posteriormente, los desarrolladores se basan

en estos casos de prueba capturados enel Manual Tester, para generar los scriptspara pruebas automatizadas. Este pro-cedimiento para generar los scripts estámetodológicamente explicado y no dalugar a errores u omisiones.

Algunos beneficios adicionales de capturar los casos de prueba con el ManualTester son:• Proporciona la posibilidad de colocarimágenes para complementar los pasos ycontribuir a eliminar ambigüedad.• Permite la reutilización de patrones deprueba en diferentes pruebas.• Incluye ingreso y verificación de datoasistido durante la ejecución de las prue-bas para reducir el error humano.

ConclusiónMás allá de las herramientas, es importante que se entien-da el concepto que está detrás de todo esto. El principalobjetivo es lograr que los casos de prueba automatiza-dos, que son la clave del éxito del desarrollo dirigido porpruebas, no partan de una mala interpretación de losrequerimientos. El segundo y, no mucho menos impor-tante, es encontrar la manera de que los programadoresno dejen de ser productivos por tener que escribir casosde prueba automatizados para cada funcionalidad antesde desarrollar. Este artículo resalta estas dos cuestionesy dando un ejemplo de cómo resolverlas con un par deherramientas en particular. Pero no es necesario que selimiten a éstas. Los invito a que exploren las diferentesherramientas para pruebas automatizadas disponiblesen el mercado, y tal como yo lo hice arriben a la solucióntécnica que más les acomode, sin perder de vista los ob-jetivos propuestos.



18/60

Industria Mexicana del SoftwareUn estudio en cifrasPor Dora Luz González

En julio de 2005 se aplicó una encuestaa 68 gerentes de empresas del sector dela Industria del Software de México para co-nocer el perfil general de éstas y analizar losfactores críticos de éxito del sector. Dichaencuesta forma parte de un trabajo de inves-tigación sobre el estudio de estrategias paragenerar ventajas competitivas en la industriadel software, realizado en la Universidad Po-litécnica de Valencia, España, en el programadoctoral “Integración de las Tecnologías de laInformación en las Organizaciones”.

Antes de describir el perfil de las empresasdesarrolladoras de software en México, es im-

portante destacar que los diversos análisis quehasta la fecha se han realizado con respecto alpanorama de este sector no resultan aún ge-neralizables a toda la industria, ya que cadaestudio analiza sólo un subconjunto del totalde empresas, por lo tanto se hace la aclaraciónque lo aquí se presenta son datos representa-tivos, y no necesariamente significa que seangeneralizables.

Localización Geográfica de las EmpresasParticipantesLas empresas participantes en el estudio se lo-calizan en 11 de los 32 estados de la RepúblicaMexicana, presentando la siguiente distribu-

ción: 2.9% Chihuahua, 1.5% en Coahu44.1% en el Distrito Federal, 11.8% en Drango, 2.9% en el Estado de México, 1en Guanajuato, 2.9% en Jalisco, 2.9% en choacán, 2.9% en Morelos, 23.5% en NuLeón y 2.9% en Querétaro. Esta concención es similar a la de otros estudios realipara este sector en México [1, 2].

Número de Empresas Desarrolladoras Software en MéxicoLa respuesta a esta pregunta no tiene una exacta. De acuerdo con estimaciones realipor ESANE consultores [2] sobre del númtotal de empleados y empresas de la Indu

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 suproyecto 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 deMéxico. [email protected]



19/60

del Software en México, el número aproximado de empresas de la industriamexicana del software podría ser del orden de 1,500 empresas.

Tamaño de las EmpresasEl estudio revela que el 85.29% de las empresas del sector de la Industria Mexi-cana del Software son de tamaño micro (54.41%) y pequeño (30.88%), el5.8% mediana, y tan sólo el 8.82% son de tamaño grande (con un número deempleados mayor a 100).

Tamaño(número de Rango Porcentajeempleados)

Micro 1 a 10 54.41Pequeña 11 a 50 30.88Mediana 51 a 100 5.88Grande + de 101 8.82

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, lasmicroempresas presentan un promedio de 6 empleados, las pequeñas 23 ylas medianas 76. Para el caso de las empresas grandes, se reflejó un sesgo in-troducido por la presencia en el estudio de una empresa de tamaño grande eintensiva 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 EmpresasLa 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 delas empresas que participaron en el estudio es cercana a los 9 años. Las em-presas más antiguas se encuentran en el mercado desde hace 25 años (creadaspartir del año 1980) y las más jóvenes son menores a un año (creadas en elaño 2005).

Tomando en cuenta el tiempo de permanencia en el mercado se identificaron tres blo-ques de antigüedad de empresas: emergentes, maduras y consolidadas (ver tabla 2).

Antigüedad Porcentaje

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.

Rango de Ventas AnualesDe acuerdo a los datos obtenidos en la encuesta, la mediana del rango deventas anuales de las empresas participantes se encuentra entre 3 y 6 millonesde pesos mexicanos (Tabla 3).

En miles de Porcentajepesos mexicanos

0 a 50 3.051 a 100 4.5101 a 200 3.0201 a 500 7.6501 a 1,000 12.11001 a 3000 19.73001 a 6000 7.66001 a 12000 16.712001 a 30000 9.130,001 o más 16.7

Tabla 3. Estadísticos descriptivos de rango de

ventas anuales.

Utilidades La mediana del rango de utilidades de las empresaticipantes en el estudio, en los últimos dos años, scuentra entre el 6 y el 10%.

Rango de utilidades Porcentaje

Pérdidas 11.50 al 5% 19.76 al 10% 21.311 al 15% 18.016 al 20% 13.121% o más 16.4

Tabla 4. Estadísticos rango de utilidades en los dos últimos años.

En los tres últimos años el sector de la Industria deware de México ha registrado tasas de incremento mvadas que el ritmo de la economía nacional. En el tuvo un crecimiento del 7%, mientras que en el 200rebasó el 10% (ver “Reportaje”, SG Marzo-Abril 20

Crecimiento Laboral. En lo que respecta al análisis de los datos corresponal crecimiento laboral, se obtuvo como resultado mgeneración de 3 nuevos empleos por año (recordandel 85.29% de las empresas de este sector son de tamicro y pequeño). El 16.18% de las 68 empresas ppantes manifestaron no haber tenido crecimiento la

El 85.29% de las em-presas del sector sonmicro o pequeñas.



20/60

ESPECIAL

un 27.94% un crecimiento negativo (des-pidos), el 52.94% haber tenido un incre-mento en su plantilla laboral hasta de un

8% y un 2.94% indicó tener un crecimien-to laboral superior al 20%.

Analizando el índice de crecimiento laboralen función del tamaño de empresas, el estudioreveló que las empresas que mayor crecimien-to laboral tuvieron fueron las empresas micro(17.65%) y pequeñas (16.47%).

Origen de los Ingresos EconómicosEn lo referente al origen de los ingresoseconómicos de la empresa, se presenta enprimer lugar una predominancia hacia eldesarrollo de software hecho a la medida(40.44%), en segundo lugar están el desa-rrollo de software empaquetado (16.85%)y las actividades de consultoría (14.65%).Las actividades reportadas como “otras” serefieren básicamente a venta, renta y man-tenimiento de hardware.

¿Y los sueldos?En la tabla 5 se muestran los salarios mensua-les medios de un programador —en categoría:Software Engineer / Developer / Program-mer— para varios países donde se puede ob-servar una gran variación en los niveles deremuneración de esta actividad, desde un sa-lario mensual medio de USD $283 en Filipi-nas, hasta un salario mensual medio de USD$5,480 en Suiza, y para el caso de México es deUSD $1,865.

¿Qué Tipo de Mercado se Cubre?Del análisis correspondiente al mercado quecubren las empresas del sector, 54.78% in-dicó que cubre mercados locales, 11.86%mercados regionales, 26.24% tiene cober-tura nacional y 7.12% indica tener presen-cia internacional.

Agrupando por el tamaño de empresa y porla composición de mercado que se cubre, seobserva que la predominancia a cubrir mer-cados locales puede deberse en parte, a quela mayoría de las empresas participantes seconcentran 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 sirvie-ran como base para identificar y clasificar alos grupos con base a su orientación estra-tégica de negocio (costo y diferenciación),

se tomaron en cuenta las consideracioteóricas de: Michael Porter, Gerry Joson y Arthur Thomson. Para la mues

del estudio, las variables consideradas el análisis orientación estratégica fueporcentaje de gasto en diseño de nueproductos, porcentaje de gastos en mejen procesos, número de patentes, persodedicado a actividades de investigaciódesarrollo, porcentaje de ventas dedicamarketing y porcentaje de productos o vicios especializados.

Como resultado final para la clasificaciólas empresas en función de su orientaciótratégica se identificaron dos grupos: uno30 empresas para el grupo de estrategiacostos, y otro con 38 empresas para el gde estrategia por diferenciación (se aplitécnica estadística de análisis cluster).

ConclusiónEn este escrito se ha presentado informaobtenida a través de un estudio explorataplicado al sector de la Industria del Softde México en Julio de 2005. Se han presendo los datos más significativos de este scomo lo son: antigüedad, ventas, promediutilidades, tamaño de empresa, orientaciónegocio, generación de nuevos empleos, de sueldos, mercado que se cubre y el orde los ingresos económicos. Se espera qudatos aquí vertidos puedan servir como mde referencia e información para todas allas personas, empresas e instituciones pcas y privadas que estén inmersas o tengainterés particular en este sector.

Agradecimiento especial a cada uno de68 gerentes de las empresas participaen el estudio, a los representantes de PRSOFT, AMITI y AMCIS.

Referencias1. SE (2004), “Estudio del nivel de marez y capacidad de procesos de la indude tecnologías de información en el metropolitana de Monterrey, Nuevo Ly el Distrito Federal y su área metroptana” Secretaría de Economía del GobiMexicano.2. ESANE, Consultores S. C. y Secretde Economía, México (2004), “Perfil dIndustria Mexicana del Software y Scios Relacionados” Secretaría de EconoMéxico,Fase 1 / Criterio 2.

Tabla 5. Comparativa del salario mensual medio de

un programador de software en varios países.

País Salario mensual(2005) promedio en USDFilipinas $283Turquía $438Tailandia $510India $570Colombia $875China $899Brasil $933Emiratos ÁrabesUnidos $1,508Sudáfrica $1,558Singapur $1,616México $1,865Corea $2,183España $2,480Bélgica $2,714Nueva Zelanda $2,743 Australia $3,159Canadá $3,166 Japón $3,166Israel $3,333Suecia $3,408Finlandia $3,417Holanda $3,483Francia $3,532Irlanda $3,532Reino Unido $4,117Noruega $4,178Estados Unidos $4,416 Alemania $4,634Hong Kong $5,055Suiza $5,480

La mediana del rango deutilidades para las em-

presas de este sectoren los últimos dos años

se encuentra entre el 6 y el 10%



21/60

MAY-JUN 2006MAY-JUN 2006


22/60

ENTREVISTA

¿Qué hace el CIMAT?El CIMAT tiene tres objetivos: investigación,formación de recursos humanos y vinculacióncon empresas. En el caso de la vinculación, elCIMAT provee asesoría a organizaciones queestén interesadas en conocer sobre algún as-pecto de ingeniería de software, o que requie-ran de capacidades especiales. Debo recalcarque el objetivo del CIMAT no es vender servi-cios y competir con empresas proveedoras deservicios y consultoría en ingeniería de soft-ware. En cambio, el papel del CIMAT es apoyaral desarrollo de éstas. Por ejemplo, formarun Lead Appraiser de CMMI es muy caro y lamayoría de las empresas nacionales no puedecostearlo. Así que lo que hicimos es nosotrosgenerar a un Lead Appraiser mexicano (MiguelSerrano), y entonces que él empiece a hacerevaluaciones integrando a otros evaluadoresmexicanos, que así desarrollarán experienciae irán reuniendo los requisitos para ellos mis-mos convertirse en Lead Appraisers.

¿Cómo es diferente el rol de un académicoen México comparado con otros países?Siento que el modelo en México no facilitamucho las cosas para los académicos. Porejemplo, en otros países, como EUA, los aca-démicos pueden combinar un poco más la in-vestigación con la vinculación con empresas.En México, la única forma de que te vaya biencomo académico, es que pertenezcas al Siste-ma Nacional de Investigadores (SNI). Y al SNIlo único que le importa son las publicaciones,lo demás no cuenta. Siento que este modeloaprisiona un poco al académico en México.

¿Qué es ingeniería de software?La definición de la IEEE tiene que ver con apli-car técnicas de ingeniería al desarrollo de soft-ware. A mi me gusta la forma en como Parnasla explica, que es “todo lo que tenga que vercon realizar proyectos de software grandes ycon mucha gente”. Es una definición simplis-ta pero siento que captura el feeling. A fin decuentas, la gente es lo que le da sabor a la in-geniería de software. Mucha gente en el ám-

bito científico cree que hacer investigación eningeniería de software es hacer fórmulas parareuso, o fórmulas para demostrar la validezde un algoritmo; pero no. La mayoría de losproblemas en el desarrollo de software sonproblemas relacionados con la gente.

Esto es muy importante en nuestro país, por-que si queremos detonar la industria de soft-ware, debemos desarrollar a la gente, a losprofesionistas de software. Y éstos no nece-sitan nada más saber programar; necesitanmuchos otros conocimientos y habilidades. Sianalizas las áreas de conocimiento del cuerpode conocimiento de ingeniería de software(SWEBoK), te das cuenta que no hay ningunauniversidad en México que lo cubra todo, niprofesores para poder impartirlo. Así que ne-cesitamos desarrollar la capacidad para gene-rar ingenieros de software que cuenten con losconocimientos técnicos necesarios, pero tam-bién con habilidades interpersonales comoliderazgo, comunicación, ética.

¿Qué tanto afectan los rasgos socioculturalesen la forma de desarrollar software?Tienen cierta influencia, pero nada que no sepueda cambiar. Como mexicanos tenemosnuestra forma de hacer las cosas. Por unlado, somos muy creativos y muy trabajado-res, pero por otro tendemos a ser indisciplina-dos. Sin embargo, esto se puede revertir pormedio de educación. Somos indisciplinadosporque no nos han enseñado la ventaja de laingeniería. Por ejemplo, a nuestros alumnosde la maestría en ingeniería de software lesenseñamos a aplicar técnicas de PSP, y cuan-do salen de la maestría nos dicen “somosgente diferente, yo ya no regreso a hacer elsoftware como lo hacía antes”. Una vez quepalpan el beneficio de hacer las cosas bien, lagente sale cambiada y con un gran ímpetu decambiar el mundo. Es muy emotivo ver a losrecién egresados que dicen “es que esto lotiene que saber todo el mundo”. Tenemos elreto de generar una masa crítica de gente conesta concepción del desarrollo de software.

Ya mencionaste cómo podemos cambiar mentalidad de los profesionistas, pero, ¿quéhacemos con los directivos?Los directivos necesitan ver que la ingeniería y la calidad en el software reditúan endinero. Para lograr esto debemos recabar in-formación de proyectos, y entonces es muysencillo mostrar el retorno de inversión dehacer las cosas bien.

También tenemos el problema de que los di-rectivos en México están acostumbrados a unaforma de dirigir de “látigo” o capataz. No confiamos en que nuestros ingenieros tengan lacapacidad de proveer resultados de forma au-tónoma. Y probablemente esto sea cierto (queen general no se tenga esa capacidad), por esoes necesario generar esa masa crítica de bue-nos y verdaderos ingenieros de software.

¿Qué crees que debería saber un recién graduado de nivel licenciatura?Si pretendemos competir con la India, debería salir sabiendo todo lo que dice el SWEBoy dominar alguna plataforma. En otros paísesestos conocimientos se adquieren hasta quelos profesionistas están en las empresas. Porejemplo, las empresas en India dedican enpromedio 10% de sus ingresos a la capacitación. Esto es algo que no podemos hacer enMéxico, dado que la industria no puede so-portarlo. Así que los egresados deben salirlistos para ser productivos en la industria.

¿Crees que la academia en México está haciendo su trabajo?Creo que se está quedando corta. Tieneque ver con muchos factores. Por un ladono hay buenos profesores porque no sonbien pagados. Por otro, la academia estámuy desconectada de la industria. Es fundamental que los profesores participen enproyectos de la industria, y que los alum-nos tengan prácticas profesionales. ¿Tú teimaginas que una persona que jamás haagarrado un bisturí en su vida, enseñara asus alumnos cómo hacer una cirugía? Se

Dr. Carlos Montes de OcaCentro de Investigación en Matemáticas (CIMAT)

Como sabemos, la academia juega un rol fundamental en el desarrollo de la industria de softwUna de las instituciones académicas de mayor prestigio y especialización en ingeniería de softwael CIMAT, en Guanajuato. Carlos Montes de Oca es uno de los gurús en el Departamento de CComputacionales del CIMAT, y en esta ocasión comparte con nosotros su visión sobre la ingenisoftware, la importancia de ésta, y los retos que enfrenta la academia en el desarrollo de la indude software en México.



23/60

ría terrible. Pero esto es lo que estamoshaciendo. Ahora, ¿tú concibes una carrera

de medicina sin un hospital al lado? Puesno, ¿verdad? En el software debería de serigual. Las escuelas de ingeniería de soft-ware deberían tener al lado una fábrica desoftware o algo donde los alumnos pue-dan participar en proyectos reales. Porquela ingeniería de software es especial y re-quiere de práctica y tutelaje.

¿Realmente hay una oportunidad para Méxicoen la industria de software mundial?La verdad, yo creo que la oportunidad gran-de ya se nos pasó. Si las cosas estaban difí-ciles con India, con China va a estar muchopeor. Son muchísimos, tienen tarifas muchomenores, y la India les está transfiriendotodo el conocimiento en calidad.

México sigue teniendo la buena oportunidadde que está pegado a Estados Unidos. Ese esel nicho que nos queda, pero tenemos queaprovecharlo y ponernos las pilas, porquehasta ése se nos puede ir. Para desarrollarbuenos profesionistas, necesitamos un ciclode cuatro años, y todavía no lo empezamos.Así que de aquí a cuatro años, no vamos aestar listos. Necesitamos apurarnos.

¿Alguna recomendación para los lectoresde SG?Primero, que conozcan y apliquen las técni-cas de ingeniería de software. Segundo, quese metan de lleno en procesos y calidad.Cuando nos caiga el veinte que la formamás eficiente y efectiva de hacer las cosases hacerlas bien la primera vez, le vamos adar un gran giro a la industria. Por último,que entiendan la importancia de la gente.Con este fin voy a hacer una última analo-gía: el dueño de una fábrica de coches salea las 6 de la tarde, y ahí tiene su fábrica, consu valor intacto; puede venderla y recuperarsu inversión. En cambio, el dueño de una fá-brica de software, a las 8 de la noche quesus empleados ya se fueron a su casa, estádescapitalizado. Lo único que tiene son es-critorios y unas máquinas depreciadas.

Como industria, debemos reconocer queestamos hechos de personas, y que éstasson nuestro principal activo. Así que debe-mos tenerlas bien “aceitadas” (a través decapacitación y motivación) para obtener sumáximo rendimiento.



24/60

EN PORTADA

Las necesidades de un cliente pueden sufrircambios importantes del momento de contra-tación de un proyecto de software, al momen-to de su entrega; y es mucho más importantesatisfacer estas últimas que las primeras. Estorequiere procesos de software diferentes, queen lugar de rechazar los cambios, sean capacesde incorporarlos. Dichos procesos también de-ben:• Producir versiones ejecutables del softwareen pocas semanas, con el fin de quedar biencon el cliente y obtener retroalimentación encuanto al producto.• Inventar soluciones sencillas, de tal formaque el impacto de los cambios se minimice.• Mejorar la calidad del diseño de maneracontinua, haciendo que la siguiente iteraciónrequiera menos esfuerzo que la actual.

• Probar desde temprano y de manera conti-nua, para encontrar defectos antes de que ten-gan un alto impacto.En los últimos años hemos visto surgir métodosque capturan y fomentan dichas prácticas, y ensu conjunto son conocidos como métodos “Ági-les”. Algunos de estos cuentan con más de unadécada de existencia. Sin embargo, fue en el año2001, cuando varios de sus creadores se reunie-ron para formar la “Alianza Ágil” y dar a conocerel “Manifiesto Ágil”, que define los valores enque se basan dichos métodos:• Individuos e interacciones por encima deprocesos y herramientas.• Software funcional por encima de documen-tación abundante.• Colaboración con los clientes por encima denegociación de contratos.

• Respuesta al cambio por encima de semiento a planes.

De acuerdo con Jim Highsmith y AlisCockburn, ambos miembros fundadoresdicha alianza, lo nuevo de estos métodoson las prácticas que utilizan, sino su reccimiento de la gente como principal fade éxito de los proyectos. AdicionalmeCockburn define estos métodos como elde reglas “ligeras pero suficientes” y la ación de técnicas orientadas a las personascomunicación.

En las páginas siguientes conoceremossobre los métodos ágiles y su aplicacióaprenderemos a distinguir entre los mitrealidades asociados a estos.

Sin duda alguna, ser “ágil” es lo de hoy. Con esto, nos referimos a la capacidad para proveer respuestas radaptables al cambio. Ambas cualidades siempre habían sido deseables, pero en el entorno de negocioindispensables. Este requerimiento de agilidad en las empresas, gobiernos, y cualquier otra organización, el software (que a fin de cuentas es el motor del mundo actual) también deba ser desarrollado de manera



25/60

eXtreme Programming (XP)www.extremeprogramming.org XP es probablemente el método ágil que másatención ha recibido desde que fue dado a co-nocer en 1999 a través del libro “Extreme Pro-gramming Explained” de Kent Beck. XP estáformado por valores, principios y prácticas.Las prácticas son actividades concretas que unequipo puede realizar día a día, mientras quelos valores representan el conocimiento fun-damental que sustenta dichas prácticas. Tantolos valores como las prácticas son necesarios,pero hay un gran espacio entre ambos. Estabrecha es cubierta por los principios. La edi-ción actual de XP (2004) define cinco valores,catorce principios, trece prácticas primarias yonce prácticas adicionales.

Los cinco valores son:• Comunicación. La comunicación entremiembros del equipo y con clientes, se debemaximizar.• Simplicidad. Usar la solución más sencillaque pueda funcionar.• Retroalimentación. Siempre debe ser posi-ble medir el producto que se está desarrollan-do, y conocer qué le falta para satisfacer losrequerimientos.• Coraje. Es necesario armarse de valor paraincorporar cambios durante un proyecto. Elcoraje por sí sólo es peligroso, pero sustentadocon comunicación, simplicidad y retroalimen-tación, es una herramienta poderosa.• Respeto. Los valores anteriores implican res-peto. Ninguna metodología puede funcionarmientras los miembros del equipo no se tenganrespeto entre sí, ni al trabajo que realizan.

Entre las prácticas más significativas de XPestán el diseño incremental, programación enpares (dos personas en una computadora), in-

tegración continua (cada dos horas), ytest-first programming (antes de desarrollar código nue-vo, debes crear las pruebas que van a verificareste código).

Scrumwww.controlchaos.comScrum fue desarrollado durante los ochentasy noventas por Ken Schwaber, Jeff Suther-land y Mike Beedle. Este método se concen-tra en la administración de los proyectos desoftware, dividiendo el desarrollo en itera-ciones de 30 días (denominadas “sprints”),y monitoreando/controlando el proyecto através de juntas diarias. De hecho, “scrum”se refiere a la jugada en el rugby donde los jugadores trabajan en equipo para obtenerposesión del balón.

Scrum aplica ideas de la teoría de control deprocesos industriales con el objetivo de lograradaptabilidad y productividad. Scrum no de-fine actividades ni técnicas específicas para laconstrucción de software. En cambio, se con-centra en las reglas de funcionamiento de unequipo de trabajo para poder producir siste-mas flexibles en un ambiente de cambios.

Dado que Scrum hace poco énfasis en las acti-vidades de ingeniería, es común complemen-tarlo con otros métodos fuertes en cuanto aprácticas de ingeniería, como lo es XP.

CrystalCrystal es una familia de métodos que com-parten principios en común. Estos princi-pios comunes, o “código genético” (comolo llama su creador Alistair Cockburn), seenfocan en las entregas frecuentes, la comu-nicación cercana y la mejora a través de lareflexión. Existen diferentes métodos Crystal

para diferentes tipos de proyectos, y lasganizaciones pueden personalizar un proespecífico para cada proyecto.

El nombre Crystal surge de la caracterizde los proyectos de software de acuerdo tamaño e importancia (criticality) del proda desarrollar, de la misma forma que los cles son caracterizados por su color y duretamaño del proyecto indica el método a uzar —Crystal Clear es para equipos pequ(menos de 8 personas), seguido por Yellowa 20), Orange (20 a 50), y así sucesivamhasta Violet—, mientras que la importancidica la dureza con que se debe aplicar, estacuarzo (quartz) hasta diamante (diamond)

Las prioridades que comparten todos lostodos de Crystal son:• Seguridad en el desenlace del proyecto.• Eficiencia en el desarrollo.• Habitabilidad de las reglas (el equipo siente cómodo con ellas).

El énfasis de las metodologías Crystalen la comunicación y la cooperación elas personas. De hecho, a diferencia de ométodos que se centran en arquitectura, pcesos, o incluso herramientas, podríamocir que Crystal está “centrado en perso( people-centric ).

A pesar de su popularidad, no existe un web que sirva como punto central paranocer más sobre Crystal. El sitio de AliCockburn (alistair.cockburn.us) contieneferencias a algunos sitios y artículos, sinbargo la mejor fuente de conocimiento sCrystal es el libro titulado Crystal Clearcrito por Cockburn y publicado por Addi Wesley en 2004.

Diferentes Sabores paraDistintas NecesidadesExiste una gran variedad de métodos ágiles. Aunque todos se basamanifiesto ágil y sus principios, cada uno cuenta con enfoques y prparticulares. Este artículo brinda un panorama sobre algunos de los mmás significativos.

Ninguna metodología puede funcionar mien-

tras los miembros delequipo no se tengan

respeto entre sí, ni altrabajo que realizan.



26/60


27/60

MAY-JUN 2006

la calidad necesaria para que el cliente puedausarlo por sí mismo. Esto le permitirá tenerun mejor entendimiento sobre a dónde quieredirigir el desarrollo de su producto. Ademásde que le permitirá ver un progreso real sobresu proyecto, en un corto tiempo. Idealmente,la reunión de presentación al final del sprintdebiera fungir como la junta de planeacióndel próximo sprint.

Pero... ¿En Realidad Funciona?La premisa básica de scrum, y en gran medidade los métodos ágiles, es que si el colaboradorestá comprometido con el equipo de trabajo,y el jefe confía en ellos, entonces el equipoinvierte el tiempo en producir algo, en lugarde estar justificando el avance o falta del mis-mo. Esto reduce la necesidad de reuniones yreportes de situación. Básicamente, se parecemucho a las tareas universitarias, en las queel profesor dice qué hay que hacer y cuandohay que entregarlo. Al principio, todos losinvolucrados, y en especial el equipo de tra-bajo, se sentirán extraños, pues no hay unaestructura centralizada de control. Pero enel momento en que el equipo se organiza, lafalta de control central se vuelve la principalventaja del método.

Es muy difícil otorgarle al equipo de trabajo elcontrol que requiere scrum. La técnica es aven-turada, y existe un riesgo de toparse con límitesreales, que puedan llegar a cancelar el proyecto.Una falla puede tener mucho impacto en losmiembros del equipo de trabajo por los nivelesde envolvimiento personal con el proyecto.

Lo Que No Funciona A continuación comparto una lista de lastrampas más comunes de una implementa-ción primeriza de scrum en una organizacióncon métodos tradicionales, y que en mi ex-periencia son señales claras de que no se estátrabajando de acuerdo al principio inicial descrum de autorregulación.• La junta scrum no es un reporte de avan-ce. Los participantes del equipo deben ver la junta scrum como una oportunidad para re-solver sus problemas inmediatos. Una claraseñal de que las juntas no están funcionan-do como deberían es que los integrantes delequipo miran al dueño del scrum y le relatansus actividades, como en un reporte de situa-ción, en lugar de hablar entre ellos o solicitarla intervención del dueño del scrum en algúnasunto relacionado con las áreas periféricas dela organización.

• No se contemplan todas las actividades cesarias en el sprint . Esto es, se viola el principdel sashimi, siempre tener un producto entrble para el usuario final. Es muy común qulos primeros sprints se olviden algunas adades, típicamente las que se podrían clasde poco ágiles o poco sexy, como mantenedocumentos o los manuales de usuario. Esmal, pero también es importante que se corrrumbo una vez detectado esto. Una actividapuede considerarse completa sin estos prodadicionales. El dueño del scrum debiera dcentivar que un miembro del equipo cambactividad antes de terminarla por completo• Interferir con el equipo de trabajo duranel scrum. Es muy tentador para el dueño dproducto acercarse al equipo para solicitapequeño cambio. Y es también muy fácilel equipo aceptarlo – al fin y al cabo, estsiendo ágiles, ¿o no? El dueño del scrum combatir estas intervenciones para mantal equipo centrado en entregar la funciodad en tiempo y en forma.

Referencias• www.controlchaos.com • Ken Schwaber. Agile Project Managem

with Scrum. 2004, Microsoft Press

Cada sprint duraun mes y se

cierra con una presentación



28/60

EN PORTADA

John Gómez es PMP y se desempeña como Consultor Senior para mejora de procesos en Practia Consulting Chile. Tiene más de 15 años de experiencia en proyectos dedesarrollo de software asumiendo roles de programador, diseñador, arquitecto y jefe de proyecto. Desde el año 2002 colabora con la implementación de prácticas ágiles enproyectos de desarrollo y ha dirigido proyectos de mejora basados únicamente en metodologías ágiles. John ha sido relator de charlas sobre metodologías ágiles en variasoportunidades incluyendo las ediciones de SEPG LA de 2005 y 2006.

Mitos yRealidadesConociendo los ExtremosPor John Gomez

Si bien las metodologías ágiles ve-nían gestándose y aplicándose des-de los años noventa, la formaciónde la Alianza Ágil y subsiguientepublicación del Manifiesto paraDesarrollo de Software Ágil en fe-brero del 2001, marcaron una in-flexión en el uso de procesos paradesarrollo de software desatandouna fuerte polémica entre promo-tores y detractores de lo “ágil”.Las malas interpretaciones de uno y otro ladomarcaron el tono de la discusión que cada vez sehizo más radical. Sería pretencioso querer resol-ver en este artículo toda esta polémica; el objetivoes ilustrar algunos de los principales puntos endisputa, aclarando los conceptos erróneamenteinterpretados sin tomar partido por ninguno delos dos bandos.



29/60

Ni “Silver Bullet” ni“Licencia para Hackear”Kent Beck, creador de Extreme Programming(XP), comenta que tuvo esta conversación con unpracticante:

Agradecido practicante: Sr. Beck, tengo que agra-decerle, XP nos cambió la vida, sin embargo, ahora

tenemos algunos problemas con el testing.Kent Beck: Muchas gracias. ¿Quiere decir que no logran codificar las pruebas antes de los programas? AP: Bueno, en realidad no codificamos pruebas...KB: Entiendo, ¿entonces logran realizar integración

frecuente generando una nueva versión funcional almenos una vez al día?

AP: Mmm, en realidad no...KB: ¿Pero funcionan la programación en pares, lashistorias de usuario o el refactoring?

AP: Mmm, no...KB: Entonces, ¿cómo es que hacen XP?

AP: Ah, bueno, dejamos de documentar...

Beck ejemplificaba de esta forma exagerada loque estaba dándose en la realidad: las nuevasmetodologías fueron acogidas por muchospracticantes con gran entusiasmo y poco crite-rio. Además, a partir de un par de experienciasexitosas muchos se dedicaron a criticar condesprecio la llamada ingeniería “tradicional”.

Del otro bando también surgieron posicionesradicales. Steven Rakitin envió a los editoresde IEEE Computer una carta con la siguienteinterpretación escéptica del Manifiesto:• Individuos y sus interacciones sobre pro-cesos y herramientas.Traducción:hablar conla gente nos da la flexibilidad de hacer lo quenosotros queramos de la forma en que queramos.Por supuesto, se da por sentado que nosotros sabe-mos lo que usted quiere, incluso si usted no”.• Software funcional sobre documentaciónexhaustiva.Traducción:queremos pasar todoel tiempo codificando. ¡Los verdaderos progra-madores no escriben documentos! • Colaboración con el cliente sobrenegociación de contratos.Traducción:“no per-damos tiempo discutiendo detalles, eso limita nues-tra capacidad de pasar todo el tiempo codificando.Ya veremos qué pasa cuando entreguemos algo”.• Responder al cambio sobre seguimiento deun plan.Traducción:“seguir un plan significaque deebemos pensar en el problema y cómo vamosrealmente a resolverlo. ¿Por qué gastar tiempo eneso cuando podríamos estar codificando?”.

Estos extremos reflejan lo álgido de la discu-sión. Para algunos las metodologías ágiles eranla nueva “bala de plata” que venía a triunfardonde la ingeniería “tradicional” había fraca-sado. Para otros, las metodologías ágiles eransólo una excusa para desarrollar software sinplanes, diseño ni documentación. Ambos

extremos son erróneos; por una parte, variasprácticas ágiles tienen nichos donde fun-cionan muy bien, pero hay otros ambientesdonde pierden su efectividad o deben ser mo-dificadas para lograr el objetivo. Sólo hay queimaginar realizar la reunión diaria de segui-miento que propone SCRUM, XP o Crystal

en un proyecto con cincuenta personas.Tampoco es correcto que lo ágil se contra-ponga a la ingeniería de software. De hecho,muchas prácticas ágiles vienen de estudiosrealizados desde antes de la década de los se-sentas. Varios de los autores de estas metodo-logías vienen de la comunidad de desarrolloorientado a objetos, donde se gestaron variosde los avances más importantes en arquitec-tura y diseño de software. Este y otros puntosse tocarán en mayor detalle empezando poruno de los más discutidos: el ciclo de vidade desarrollo.

El Mito de la CascadaDespués de conocer tantos equipos de pro-yecto aún me asombra como para muchos elúnico ciclo de vida conocido es el de cascada,donde se ejecutan secuencialmente las activi-dades de análisis, diseño, construcción, etc.

RUP y las metodologías ágiles han contribuidoa generar más visibilidad sobre los ciclos de vidaiterativos e incrementales, pero se han dadoalgunas confusiones. Primero, erróneamentemuchos practicantes de las metodologías ági-les creen que los ciclos de vida incrementalesson exclusivos de estas o que son propuestospor ellas. Esto dista mucho de la realidad: hayevidencias de la definición y uso de ciclos devida incrementales incluso en los años cincuen-ta. Un ejemplo es el ciclo de vida evolutivo enespiral de Boehm [Boehm86].

Otro gran error cometido tanto por agilistascomo por tradicionalistas, es asumir que elciclo de vida en cascada es absolutamente se-cuencial. He conocido ingenieros que estánconvencidos de que es posible realizar todoel trabajo de requerimientos antes de iniciarel diseño de modo que dicha etapa se “cierre”y no haya necesidad de volver atrás. Creer enesto es negar que se vayan a presentar cam-bios a los requerimientos en etapas posterio-res del desarrollo lo cual es querer tapar el solcon las manos.

El ciclo de vida en cascada secuencial data de1957 [Benington57], sin embargo el ciclo de vidaen cascada conocido hoy es la versión de Royce[Royce70]. En esta propuesta, el ciclo de vida encascada tiene una visión incremental, reconocien-do que el cambio es innegable y que por lo tanto

siempre habrá que volver atrás para refinar svamente los resultados de cada etapa de accon los cambios que se presentan.

La elección del ciclo de vida debe realisegún las condiciones del proyecto. ¿Qupráctico es planear iteraciones para un m

nimiento donde trabajan dos personas popar de días? También pasa que es muchosencillo planificar un proyecto con ciclvida en cascada; además, los procesos detión de configuración e integración debenmucho más rigurosos en el desarrollo inmental. Por otro lado, sería suicida propoun desarrollo en cascada en un proyectoalta incertidumbre donde los requerimieson vagos o muy susceptibles de cambio.

En resumen, ni cascada significa fracaso-caísmo, ni incremental significa éxito o cada equipo debe decidir cuál es el cicloconveniente para su proyecto.Ingeniería vs. AgilidadLa rigurosidad y disciplina en las prácticingeniería también se ha discutido muchodiscurso de los “agilistas” de erradicar elen cascada y por lo tanto las grandes etapanálisis y diseño antes de construir cualqparte del producto ha llevado a la mala inpretación de que en las metodologías ágidesincentivan las prácticas de ingenierísoftware. Esto se complementa con la apatemente declarada aversión a la documeción presente en las metodologías ágiles.

En realidad las metodologías ágiles propreducir las actividades tipo “big up-front”ejemplo, cuando el equipo tiene que dedicdías enteros a actividades de diseño antecodificar. En cambio se propone que el disea una actividad permanente cuyos resdos se validan continuamente a la luz dconstruido. Según esto, el equipo dedica riamente una parte de su tiempo a actividde diseño, el cual evoluciona en paralelo cconstrucción. Esto se complementa con oprácticas: la integración frecuente presenla mayoría de las metodologías ágiles sólode sostenerse con el respaldo de un adectrabajo de diseño.

Otro tema es la documentación. Mucpracticantes de los métodos tradicionalesimplementado sus procesos con dependeextrema de los documentos. Malas interpciones han llevado a que una compañía tun estándar de plan de proyecto de 20 ciones y 40 páginas y lo exija para todoproyectos sin importar si uno es de 60 hhombre y otro de 6000.



30/60

También he visto como compañías exigen asus equipos documentar el diseño usandoTODOS los diagramas de UML, sin distin-ción de cuáles son realmente útiles para cadaproyecto o situación.

El otro extremo también se presenta debido a unamala interpretación. Críticos de las metodologíaságiles y muchos de sus practicantes han creídoque no hay valor en documentar. Si bien variosautores han asumido posiciones relativamente ex-tremas sobre el asunto, en general hay consensoen que cada equipo debe determinar la cantidady forma de documentación requerida, sea que seuse el generador de reportes de la herramienta demodelado, o una foto de la pizarra de la sesiónde diseño. Además, deben tomarse en cuenta losrequerimientos del cliente y condiciones debidasa regulaciones o estándares. Cumplir con los re-querimientos de documentación no significa queel equipo deje de ser “ágil”.

Finalmente, la documentación no reemplaza lacomunicación. Más de una vez he visto comola información de requerimientos se comparteen un equipo enviando el documento de casosde uso por e-mail: ¿es posible que se logre en-tendimiento de esta forma?

“Predecible” versus“Adaptable”: ¿Planificamos o No?Varios agilistas han coincidido en describir losprocesos ágiles como “adaptables” en contrapo-sición a los métodos tradicionales o “dirigidospor planes”. Hay malas interpretaciones sobreesto también. Los agilistas critican que se pre-tende planificar en excesivo detalle asumiendoque hay una capacidad de predicción que noes posible. Los tradicionalistas responden afir-mando que no hay planificación en lo “ágil”.He visto líderes de proyecto que pasan semanasdesarrollando un plan de trabajo, estableciendoen el cronograma actividades de 1 ó 2 horas deduración que se van a iniciar en 6 meses más.Son pocos los proyectos de software que se pue-

den predecir con ese nivel de precisión, y por lotanto lo más probable es que esas actividades seredefinan y el esfuerzo en planificación sea undesperdicio. Ningún método tradicional pro-pone esto como buena práctica.

Por otro lado, es erróneo indicar que en los

métodos ágiles no hay planificación. Todos in-cluyen prácticas específicas al respecto dondelo que está variando es la estrategia empleaday las técnicas utilizadas. En los métodos ágilespuede haber varios niveles de planificación:un plan de “releases” de alto nivel, un plan deiteraciones con un poco más de detalle y final-mente un plan de iteración donde aparecenlas actividades concretas. También es erróneopensar que estas técnicas son exclusivas de lasmetodologías ágiles. Esta planificación porventanas o “Rolling Wave Planning” es unatécnica recomendada por el PMBOK.

La connotación de predecible versus adaptabletambién está asociada a críticas a los métodos tra-dicionales indicando que no pueden o no sabenlidiar eficientemente con el cambio. Malas in-terpretaciones han llevado a equipos a establecerexcesivos y rigurosos procesos de control de cam-bio. Pocos métodos tradicionales establecen queel cambio debe ser limitado. La incertidumbre enlos requerimientos y por lo tanto la omnipresen-cia del cambio ha sido aceptada desde siempre.

El Factor HumanoUno de los puntos más distintivos de las meto-dologías ágiles fue su reconocimiento explícito deque la gente y sus interacciones eran el factor másimportante de éxito en los proyectos de software.Sobre esto también ha habido confusiones. Parae

,etodologias agiles.pdf

Documents