SG #09

Scrum: Caos controlado

Anonymous — Wed, 26 Sep 2007 18:39:10 +0000

Scrum: Caos controlado

Anonymous Wed, 09/26/2007 - 13:39

Publicado en

SG #09

Agilidad

Autor

Luis Guerrero

Scrum es un proceso ágil de administración de proyectos. Por su naturaleza es iterativo y pretende tener un producto listo al final de cada iteración. Toma su nombre de una jugada de rugby, y que Ken Schwaber, uno de los padres del método, describe como “caos controlado”.

Historia

En 1995, Ken Schwaber, un metodólogo de software reconocido, decidió descubrir porqué las metodologías de desarrollo funcionaban tan mal cuando se intentaban seguir al pie de la letra. Con este fin, reunió a varios expertos de teoría de procesos de DuPont, y les presentó diversas metodologías. La respuesta de los expertos fue reveladora e inesperada. La industria de desarrollo de sistemas está usando el modelo de control de procesos equivocado. Existen dos aproximaciones al control de procesos:

El proceso definido, en el que todos los elementos y componentes son bien conocidos y controlados. Dado un conjunto de entradas, se obtiene un conjunto de salidas igual y consistente siempre.
El proceso empírico, por otro lado, espera lo inesperado. Como no se conoce el proceso con suficiente detalle, y producen resultados inesperados e irrepetibles, la única manera de controlarlos es a través de inspecciones constantes y minúsculas correcciones aplicadas con frecuencia.

El desarrollo de software, siendo una actividad tan profundamente intelectual, y que necesita tanta creatividad, es un mal candidato al proceso definido. El desarrollo de software, entonces, no debería entenderse como una línea de montaje, sino como una serie de inspecciones constantes acompañadas de correcciones inmediatas. Schwaber llama a esta forma de trabajar el proceso caórdico, y nota que espontáneamente, los equipos de trabajo se coordinan con muy poca intervención de entidades externas. Schwaber llama a este proceso la auto-organización

Roles de Scrum

Hay cuatro roles para los participantes de un proyecto que se administre con scrum:

Dueño del producto. Es quien determina las prioridades. Debe ser una sola persona.
Dueño del scrum. Administra y facilita la ejecución del proceso.
Equipo de trabajo. Son los encargados de entregar resultados al final del sprint.
Interesados. Asesoran y observan el proceso. Tienen interés en el resultado final.

El Scrum

El método es iterativo en su naturaleza. Cada iteración, o sprint, dura un mes calendario. Este inicia con una reunión entre el equipo de trabajo, el dueño del scrum (scrum-master) y los patrocinadores del proyecto. En esta reunión, los patrocinadores exponen y aclaran los requerimientos del proyecto, y también se encargan de priorizarlos. Este es el alcance acumulado del producto (product backlog). Posteriormente el equipo de trabajo decide qué funcionalidad puede entregar al final del sprint – el alcance acumulado del sprint (sprint backlog).

Es de gran importancia que los patrocinadores del proyecto respeten el alcance, y no alteren o interfieran con el equipo de trabajo durante el sprint. Aquí se hace una estimación inicial del trabajo necesario para entregar la pila del sprint. También es indispensable no violar el principio ágil de trabajar únicamente 40 horas a la semana. Después de esta reunión, el equipo es libre de organizarse como considere conveniente. Cada día, el equipo de trabajo se reúne con el dueño del scrum en la junta scrum.

La Junta Scrum

La junta scrum debe ser breve, no más de 15 minutos al día. Si no se puede mantener en esos niveles, entonces hay muchas personas. Será necesario identificar quién debe participar en esa reunión. En esta reunión, se le toma el pulso diario al proyecto. El dueño del scrum detecta qué problemas existen, y busca quitarlos de en medio, fungiendo como un facilitador más que como un líder de proyecto.

El objetivo principal de la junta scrum es que los participantes del sprint hablen entre ellos y descubran qué necesidades tienen, las resuelvan en el momento, y si no es posible, buscar los foros adecuados posteriormente. En esta reunión se hacen estimaciones del trabajo restante de cada participante. Estas estimaciones se recogen y tabulan en las gráficas de consumo. Estas gráficas deben mostrar que el trabajo pendiente para entregar la funcionalidad acordada debe disminuir con el paso del tiempo, de otra manera, lo que demuestran es que el equipo fue demasiado optimista y ahora se está enfrentando con la realidad. El maestro del scrum puede tomar la decisión de acordar una disminución del alcance con el dueño del producto, o informarle con tiempo que no se va a lograr la meta, pero que es lo que sí es realmente factible. En el caso remoto de que los resultados sean de verdad terribles, es posible cancelar todo el sprint.

Sashimi

El sashimi es un plato japonés en el que se presentan finas rodajas de pescado apoyadas parcialmente sobre la anterior. En el contexto de scrum, y de los métodos ágiles en general, cada rebanada se entiende como un pedacito del todo que está listo para consumirse en cualquier momento. Cuando se planean las actividades del scrum, los productos resultantes deben estar listos para consumo del usuario. Eso quiere decir que no sólo debemos contar con el sistema de software. También debe estar lista la documentación, el instalador, y el manual de usuario, por ejemplo.

La Presentación

Al final del sprint se hace una presentación con el dueño del producto. En esta reunión se evalúa el resultado del sprint, y se revisa el alcance acumulado del producto, y con base al producto que el usuario final tiene ahora, se revaloran los requerimientos, para escoger un nuevo alcance para el próximo sprint. Es importante que el producto final del sprint tenga la calidad necesaria para que el cliente pueda usarlo por sí mismo. Esto le permitirá tener un mejor entendimiento sobre a dónde quiere dirigir el desarrollo de su producto. Además de que le permitirá ver un progreso real sobre su proyecto, en un corto tiempo. Idealmente, la reunión de presentación al final del sprint debiera fungir como la junta de planeación del próximo sprint.

Pero... ¿En Realidad Funciona?

La premisa básica de scrum, y en gran medida de los métodos ágiles, es que si el colaborador está comprometido con el equipo de trabajo, y el jefe confía en ellos, entonces el equipo invierte el tiempo en producir algo, en lugar de estar justificando el avance o falta del mismo. Esto reduce la necesidad de reuniones y reportes de situación. Básicamente, se parece mucho a las tareas universitarias, en las que el profesor dice qué hay que hacer y cuando hay que entregarlo. Al principio, todos los involucrados, y en especial el equipo de trabajo, se sentirán extraños, pues no hay una estructura centralizada de control. Pero en el momento en que el equipo se organiza, la falta de control central se vuelve la principal ventaja del método.

Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aventurada, y existe un riesgo de toparse con límites reales, que puedan llegar a cancelar el proyecto. Una falla puede tener mucho impacto en los miembros del equipo de trabajo por los niveles de envolvimiento personal con el proyecto.

Lo Que No Funciona

A continuación comparto una lista de las trampas más comunes de una implementación primeriza de scrum en una organización con métodos tradicionales, y que en mi experiencia son señales claras de que no se está trabajando de acuerdo al principio inicial de scrum de autorregulación.

La junta scrum no es un reporte de avance. Los participantes del equipo deben ver la junta scrum como una oportunidad para resolver sus problemas inmediatos. Una clara señal de que las juntas no están funcionando como deberían es que los integrantes del equipo miran al dueño del scrum y le relatan sus actividades, como en un reporte de situación, en lugar de hablar entre ellos o solicitar la intervención del dueño del scrum en algún asunto relacionado con las áreas periféricas de la organización.

No se contemplan todas las actividades necesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entregable para el usuario final. Es muy común que en los primeros sprints se olviden algunas actividades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es normal, pero también es importante que se corrija el rumbo una vez detectado esto. Una actividad no puede considerarse completa sin estos productos adicionales. El dueño del scrum debiera desincentivar que un miembro del equipo cambie de actividad antes de terminarla por completo.
Interferir con el equipo de trabajo durante el scrum. Es muy tentador para el dueño del producto acercarse al equipo para solicitar un pequeño cambio. Y es también muy fácil para el equipo aceptarlo – al fin y al cabo, estamos siendo ágiles, ¿o no? El dueño del scrum debe combatir estas intervenciones para mantener al equipo centrado en entregar la funcionalidad en tiempo y en forma.

Referencias

www.controlchaos.com
Ken Schwaber. Agile Project Management with Scrum. 2004, Microsoft Press

Bio

Luis Guerrero es Arquitecto de Sistemas en el Sistema de Administración Tributario (SAT). Sus áreas de especialidad son procesos, ingeniería de software, seguridad y métodos ágiles. Durante su trayectoria profesional ha trabajado en México, las Antillas y Centroamérica, en proyectos empresariales y para el gobierno federal.

Industria Mexicana del Software. Un estudio en cifras.

Anonymous — Wed, 26 Sep 2007 18:04:13 +0000

Industria Mexicana del Software. Un estudio en cifras.

Anonymous Wed, 09/26/2007 - 13:04

Publicado en

SG #09

Industria

Autor

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

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

Tabla 2. Antigüedad.

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

Tabla 3. Estadísticos descriptivos de rango de ventas anuales.

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

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

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,

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 2005. 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 PROSOFT, 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 2.

Acerca del autor
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

Historia y futuro de la Ingeniería de Software. Visión de Barry Boehm.

Anonymous — Sun, 23 Sep 2007 18:28:47 +0000

Historia y futuro de la Ingeniería de Software. Visión de Barry Boehm. Anonymous Sun, 09/23/2007 - 13:28

Publicado en

SG #09

Tejiendo nuestra red

Autor

Hanna Oktaba

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 software, 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.

Referencia

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

Bio

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 COMPETISOFT, cuyo objetivo es la mejora de procesos para fomentar la competitividad de pequeña y mediana industria de software en Iberoamérica.