Tejiendo nuestra red

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Ivett Sanchez — Tue, 15 Jan 2019 19:15:39 +0000

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Ivett Sanchez Tue, 01/15/2019 - 13:15

Publicado en

SG #58

Tejiendo nuestra red

Autor

Hanna Oktaba

Nota: Esta columna está basada en el contenido de la conferencia que ofrecí en CONISOFT’18, 24-26 de octubre de 2018, en San Luis Potosí.

Dediqué mi columna anterior a los 60 años de la computación en México, iniciados por la llegada de la primera computadora a la UNAM. Sin embargo, este no es el único aniversario redondo que nuestra comunidad debe festejar. Este año también se cumplen los 50 años del nacimiento de la Ingeniería de Software como disciplina.

Se reconoce a Margaret Hamilton, quien dirigió el desarrollo del sistema de navegación de la nave espacial Apolo por haber acuñado en 1965 el término “ingeniería de software”. Posteriormente el término también fue utilizado por personas como Anthony Oettinger (presidente de la ACM) en 1966, y Friedrich Ludwic Bauer (Comité de Ciencias de la OTAN) en 1967. Sin embargo, el nacimiento formal de esta disciplina se ubica en octubre de 1968, cuando el Comité de Ciencia de la OTAN, preocupado por lo que nombró como la Crisis de Software, convocó a los mejores científicos computacionales del momento a una reunión en Alemania.

A continuación les presento un breve resumen de los principales problemas que identificaron los asistentes, con citas del reporte de la reunión [1] en cursiva, a las cuales agrego mi visión personal de los mayores logros alcanzados durante estos 50 años.

Problemas y Logros

Proceso de desarrollo de software

Problemas en 1968

Falta una comprensión más completa del proceso de diseño del programa.
Construimos sistemas como los hermanos Wright construyeron aviones: “construye todo, empújalo por el precipicio, déjalo caer y vuelve a empezar.”

Logros hasta 2018

Durante los últimos 50 años hemos transitado por diferentes modelos: cascada, espiral, iterativo-incremental o ágil tipo Scrum. Hemos generado múltiples estándares para apoyar el desarrollo de software: CMM/CMMI, TSP/PSP, ISO/IEC 12207, 29110, 15504, MoProSoft, mps.Br o ESSENCE. Hemos integrado el cuerpo de conocimiento de la Ingeniería de Software (SWEBOK) y hemos generado el Manifiesto por el Desarrollo Ágil de Software, que está cambiando la forma de trabajar y las relaciones humanas.

A pesar de todos estos avances, tengo la sensación de que, en muchas ocasiones, seguimos imitando a los hermanos Wright. ¿Ustedes qué opinan?

Calidad de software

Problemas en 1968

Dificultades para lograr una fiabilidad suficiente en los sistemas, que cada vez son más integrados en las actividades centrales de la sociedad.
Particularmente alarmante son las fallas, aparentemente inevitables de un software, que pueden impactar una cuestión de vida o muerte.

Logros hasta 2018

La calidad de software tiene dos vertientes: del proceso y del producto. En la primera hemos avanzado introduciendo conceptos y técnicas de verificación y validación. El aseguramiento de calidad y la mejora de procesos también son un avance.

Con respecto a la calidad del producto tenemos un primer gran acuerdo en forma en el estándar ISO/IEC 25000 para identificar las características de calidad de software y su posible medición. Sin embargo, mi impresión es que para lograr la calidad nos enfocamos más en los ciclos de pruebas (testing) y sus respectivas correcciones, que en la prevención de defectos. ¿Ustedes qué opinan?

Costos

Problemas en 1968

T.J. Watson dijo que OS / 360 le costó a IBM más de 50 millones de dólares al año durante su preparación, y una inversión de al menos 5,000 años-hombre.
Los costos de desarrollo del software estaban integrados con los costos de desarrollo del hardware. No se cuantificaba el valor y costo del software como tal.

Logros hasta 2018

Para justificar el costo del software tuvimos que empezar a medir el tamaño del software. El primer intento fue usar el número de líneas de código (LOCs), pero fue criticado porque software con la misma funcionalidad puede tener diferentes tamaños LOCs dependiendo del lenguaje e incluso estilo de programación. Luego tuvimos una propuesta más sensata con los Puntos de Función ajustados a ciertos parámetros de complejidad, que eventualmente se convirtieron en el estándar ISO/IEC 14143, llamado de forma estelar “Puntos Funcionales Cosmic” :)

El problema de intangibilidad de software sigue causando estragos en la estimación de costos. La forma más popular es definir el precio en términos del costo por hora/hombre, pero hay gran discrepancia sobre cuál es la tarifa justa. Todavía es común encontrarse con quienes cuestionan por qué cuesta tanto el tiempo de las personas que desarrollan software, “si solo usan su cabeza y una computadora”. ¿Ustedes qué opinan?

Gestión

Problemas en 1968

Dificultades de cumplir fechas y especificaciones.
Dificultad para evaluar el avance real de un proyecto.
La gerencia de programación continuará mereciendo su mala reputación por la falta de efectividad en cuanto a costos y cronogramas.

Logros hasta 2018

Nos hemos apoyado en otras disciplinas. Por ejemplo, aprovechamos el cuerpo de conocimiento de la administración de proyectos PMBoK generado por el PMI. Su última publicación, el Agile Practice Guide, muestra su esfuerzo de estar al tanto de las tendencias. A pesar de estos avances, me temo que “la gerencia de programación continuará mereciendo su mala reputación” ¿Ustedes qué opinan?.

Profesión

Problemas en 1968

La ingeniería de software se encuentra en una etapa muy rudimentaria en comparación de otras ramas establecidas de la ingeniería.
Confrontaciones con ingenieros de hardware porque ellos son industriales y nosotros somos artesanos.

Logros hasta 2018

Para mejorar la profesionalización se han creado las carreras de ingeniería de software. La primera en el mundo fue fundada en 1996 en Rochester Institute of Technology por un profesor mexicano, el Dr. Fernando Náveda. La primera en México es la de la Universidad Autónoma de Yucatán en 2004.

También se han propuesto varios esquemas de certificación profesional como el Certified Software Development Professional (CSDP) de IEEE o el mexicano Estándar Técnico de Competencias para el Desarrollo de Software: Ingeniero de Software del NYCE (2014). Que yo sepa, ninguno ha tenido gran demanda. En mi opinión es porque el mercado laboral es relativamente inmaduro y prefiere las certificaciones de alguna habilidad técnica que profesional.

Los códigos de ética profesional de los desarrolladores de software tampoco han tenido gran difusión. A finales de los 1990s se creó el Código de Ética y Práctica Profesional de Ingeniería de Software de IEEE/ACM y recientemente (2018) se publicó el ACM Code of Ethics and Professional Conduct. Ambos merecen ser revisados y discutidos. Si se tomaran en cuenta nos beneficiaremos todos, pero si NO…nos amolaremos, también todos.

La profesionalización de los Ingenieros de Software ha tenido un avance significativo, pero creo que todavía nos falta elevar la conciencia del impacto que la calidad de nuestro trabajo tiene en la sociedad. ¿Ustedes qué opinan?.

Regresando a la preocupación general por la Crisis de Software del año 1968, a pesar de todos los avances y logros mencionados la situación no ha cambiado mucho. Según los reportes de Standish Chaos Group, el porcentaje de proyectos exitosos se mantiene de manera constante en aproximadamente 30%. Esto es buena noticia para ustedes, tienen mucho que innovar :).

El Futuro

El futuro de la ingeniería de software es muy desafiante. Para fundamentarlo, presento un muy breve resumen de algunas tendencias y retos abordados en la conferencia “The Future of Software Engineering” [2].

Tendencias

La computación en la nube reduce costos de arranque, y los ambientes de desarrollo en la nube facilitan el desarrollo de software remoto.

Se reduce el uso de computadoras personales a favor de los dispositivos móviles, pero su variedad es abrumadora.

Los usuarios son móviles, nómadas y "siempre conectados”.

Han surgido nuevos tipos de aplicaciones: Smart City, Internet de las Cosas (IoT), Realidad aumentada/virtual.

Inteligencia Artificial: robótica, machine learning, procesamiento de lenguaje, reconocimiento de imágenes …ya no es ciencia ficción.

Los sistemas ya casi no se hacen desde cero, evolucionan a sistemas complejos.

Retos

Estas tendencias tendrán que modificar la forma de abordar problemas y dar soluciones en la Ingeniería de Software. Sus próximos retos son los siguientes:

Se requiere el cambio profundo y radical en los métodos y técnicas utilizados para concebir, diseñar, desarrollar, probar y desplegar software.

Escalabilidad de procesos de software necesaria por la complejidad de productos y exigencia de “time to market”.

La calidad y, sobre todo, la seguridad del software se están volviendo aún más críticas.

El número de ambientes/plataformas objetivo que un desarrollador debe considerar para desarrollo de software está aumentando significativamente.

El software debe diseñarse para minimizar el uso de los recursos de hardware y de comunicación y, en consecuencia, reducir el consumo de energía (Green IT).

Conclusión

Para concluir esta columna les quiero recordar mi lema:

“La calidad de nuestras vidas depende de la calidad del software, y la calidad del software depende de la calidad de sus creadores y de las organizaciones que los respaldan.”

Referencias

P. Naur, B. Randell. Software Engineering: Report of a conference sponsored by the NATO Science Committee. Garmisch, Germany, 1968. https://sg1.run/xq
A.Fugetta y E. Di Nitto, Proceedings on the Future of Software Engineering (FOSE). Hyderabad, India, 2014. https://sg1.run/xr

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

60 Años de la Computación en la UNAM y … en México

Ivett Sanchez — Mon, 03 Sep 2018 19:38:20 +0000

60 Años de la Computación en la UNAM y … en México

Ivett Sanchez Mon, 09/03/2018 - 14:38

Publicado en

SG #57

Tejiendo nuestra red

Autor

Hanna Oktaba

La historia de la computación en México está muy ligada a la historia de la computación en la UNAM. Este año se cumplen 60 años desde la llegada de la primera computadora a esta universidad. Lo usaré como pretexto para presentarles una pequeña reseña de lo que la gente desde la UNAM ha impulsado con respecto al desarrollo de la computación en México en este periodo.

Primera computadora (1958)

En 1958 el Ing. Sergio Beltrán trae la primera computadora al recién creado Centro de Cálculo Electrónico de la Facultad de Ciencias. Fue una IBM 650, una de las primeras computadoras de propósito general construida por IBM, que pesaba alrededor de 900 kg. Fue una computadora usada, traída de una universidad de Estados Unidos (porque ellos se compraban una nueva y querían liberar el espacio) y pagada en “cómodas mensualidades”, como me lo contó en su momento Ing. Beltrán. La anécdota más completa la cuenta Dr. Felipe Bracho director actual de DGTIC (UNAM) en una entrevista [1]. En la primer fotografía que acompaña este artículo pueden apreciar una parte de la IBM 650 y en la segunda fotografía, el que está sentado del lado derecho es el Ing. Beltrán.

Figura 1. IBM 650

Figura 2. El Ing. Beltrán (derecha) con un colega

Primera institución de investigación (1970)

Durante la dirección del Dr. Renato Iturriaga de la Fuente, el Centro de Cálculo Electrónico se modernizó y adquirió tal importancia que en 1970 se convirtió primero en el Centro de Investigaciones en Matemáticas Aplicadas en Sistemas y Servicios (CIMASS), que después de separar los servicios, quedó en 1973 como Centro de Investigación en Matemáticas Aplicadas y en Sistemas (CIMAS) bajo la dirección del Dr. Tomás Garza Hernández. Este Centro se dedicaría principalmente a la investigación. Finalmente, en 1976 el CIMAS fue elevado al rango de instituto convirtiéndose en el IIMAS [2]. Hasta la fecha es la institución de investigación en la UNAM más importante en el área de la computación, complementada con la investigación en probabilidad y estadística, investigación de operaciones y aplicación de las matemáticas a problemas sociales, técnicos, científicos, económicos y administrativos. Al IIMAS llegué de Polonia como profesora visitante en 1983 y me recibieron tan bien que decidí hacer mi vida profesional en México.

Primera maestría (1975)

La Maestría en Ciencias de la Computación se creó en marzo de 1975 bajo la coordinación y organización académica del CIMAS. Es en esta maestría en la cual empecé a dar clases en 1983 y no he parado hasta el día de hoy. Entre 1990 y 1997 fui coordinadora de la maestría y, al final, junto con mis colegas la convertimos en el Posgrado en Ciencia e Ingeniería de la Computación (PCIC), que incluye también el doctorado. Ya entienden por qué le tengo tanto cariño y estoy muy orgullosa de que sus egresados tienen un papel importante en la industria de software.

Primera carrera (1977) y las que siguieron

Estas son las primeras carreras relacionadas con la computación creadas en la UNAM:

1977: Ingeniería en Computación, Facultad de Ingeniería.
1982: Matemáticas Aplicadas y Computación, FES Acatlán.
1985: Informática, Facultad de Contaduría y Administración.
1994: Ciencias de la Computación, Facultad de Ciencias.

En esta última, desde 1999, soy profesora titular ofreciendo cursos de Ingeniería de Software.

Primera Sociedad (1986) y las que siguieron

Los investigadores y profesores de la UNAM tuvieron un papel preponderante en la fundación de las sociedades y asociaciones relacionadas con la computación:

1986: Sociedad Mexicana de Inteligencia Artificial (SMIA) - Dr. José Negrete Martínez
1995: Sociedad Mexicana de Ciencia de la Computación (SMCC) – Dra. Cristina Loyo Varela, Dr. Christián Lemaitre y su servidora entre otros.
1999: Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS) - Mtr@s. Gloria Quintanilla, Guadalupe Ibargüengoitia, Francisco López Lira y su servidora.
2015 Academia Mexicana de Computación (AMEXCOMP) – Dr. Luis Alberto Pineda Cortés y 18 personas más, entre ellos su servidora como única mujer :(.

Primer acceso académico a Internet (1989)

La UNAM fue la primera universidad en Latinoamérica que introdujo acceso a Internet para uso académico. Fue por la iniciativa del Instituto de Astronomía, que necesitaba comunicarse más fácilmente con sus homólogos en Estados Unidos. Fue la primera conexión satelital. Pero la primera conexión terrestre se colocó en el ITESM en Monterrey, por un enlace telefónico de módem de 19.2 kbps hacia la Universidad de Texas en Austin. Así, hace escasos 30 años empezó la aventura de Internet en México aunque los jóvenes no lo crean :). El Dr. Erik Huesca cuenta esta historia a detalle en una entrevista disponible en el sitio de Conacyt [3].

Primera supercomputadora (1991)

La Dirección General de Servicios de Cómputo Académico (DGSCA) instaló la primer supercomputadora en Latinoamérica, una CRAY Y-MP. La figura 3 muestra una fotografía de este equipo en la Sala de Supercómputo que se construyó para albergarla. Para más imágenes, puedes consultar el Acervo histórico del cómputo en la UNAM [4].

Figura 3. Cray Y-MP en la sala de supercómputo de DGSCA

Primera Red Universitaria de Colaboración en Ingeniería de Software y Bases de Datos (2006)

En 2006 se integra un grupo de universitarios expertos en ingeniería de software y bases de datos con el objetivo de conformar una red de colaboración, intercambio y difusión del desarrollo de software de calidad, conocida como RedIS&BD. Su propósito es aprovechar la experiencia y conocimiento de los grupos de desarrollo en la UNAM para mejorar los productos de software en beneficio de la institución. Marcela Peñaloza, Facundo Ruíz Doncel, Héctor Sánchez y su servidora fuimos los integrantes del grupo promotor, coordinado hasta la fecha por Guadalupe Ibargüengoitia.

Primer Centro Virtual de Computación (2017)

El año pasado, por fin, la UNAM ha creado un Centro (aunque sea) Virtual de Computación (CviCom) [5]. Lo virtual fue necesario por la gran cantidad de personas que trabajan en las distintas áreas de computación dispersas en muchas entidades. La misión de CViCom es la coordinación de la creación de redes académicas colaborativas para fomentar la investigación, vinculación y difusión en el área de Computación y brindar apoyo a los programas educativos a nivel licenciatura y posgrado. El Centro está respaldado por 14 entidades y coordinado por Dr. Boris Escalante Ramírez. Estamos organizados en 6 áreas de conocimiento y su servidora coordina el área de Ingeniería de Software y Bases de Datos.

Espero que este breve recorrido les de una idea de que el avance de la computación en México es un esfuerzo de muchas personas en muchos frentes y que estos esfuerzos no se pueden detener. Software Gurú es un excelente ejemplo de esa labor. Al terminar de escribir la columna me di cuenta que soy “ajonjolí de muchos moles”J. Les sugiero que también lo sean, es muy divertido.

Referencias

Entrevista Dr. Felipe Bracho. http://swgu.ru/wn
Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas https://www.iimas.unam.mx
E. Rodríguez. “Historia de Internet en México”, Conacyt. http://swgu.ru/wo
Acervo Histórico del Cómputo en la UNAM. http://www.historiadelcomputo.unam.mx
“60 años del Cómputo en México”. Centro Virtual de Computación. https://cvicom.unam.mx/linea-del-tiempo

Bio

La Dra. Hanna Oktaba (@hannaoktaba) es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

¿Por Qué Siempre Me Falta el Tiempo para el Trabajo?

sg — Thu, 22 Mar 2018 03:41:04 +0000

¿Por Qué Siempre Me Falta el Tiempo para el Trabajo?

sg Wed, 03/21/2018 - 21:41

Publicado en

SG #56

Tejiendo nuestra red

Autor

Hanna Oktaba

Los cinco “ladrones” de mi tiempo

¿Por qué nos preocupamos mucho cuando nos roban una cartera o un celular y no tanto cuando nos “roban” el tiempo que no se puede recuperar de ninguna manera?

A quién no le ha pasado que se siente agobiado por la cantidad de trabajo por hacer y la falta de tiempo para hacerlo. Terminamos trabajando más horas, durmiendo menos y mal por ser angustiados, apenas saludamos a nuestros familiares o amigos y, ni de chiste nos dedicarnos a nuestros pasatiempos favoritos.

A mí me sucede eso frecuentemente, así que quiero compartir con ustedes las reflexiones del libro de Dominica DeGrandis [1] quíen nos habla de cinco ladrones de nuestro tiempo más importantes:

Demasiado trabajo comprometido (too much work-in-progress (WIP)), trabajo que se inició pero todavía no está terminado.
Dependencias desconocidas (unknown dependencies), algo que no te das cuenta que tiene que suceder para que puedas terminar tu trabajo.
Trabajo no planificado (unplanned work), interrupciones que no te permiten terminar algo o suspenderlo en mejor momento.
Prioridades en conflicto (conflicting priorities), proyectos o actividades que compiten entre sí y no estás seguro cuál es el más importante.
Trabajo descuidado (neglected work) trabajo parcialmente realizado que dejaste en el olvido.

Ya se pueden imaginar de qué se trata pero acompáñenme para revisarlos uno por uno.

Demasiado trabajo comprometido

A mi me pasa frecuentemente porque no sé decir NO. ¿Y por qué no sabemos decir NO? Porque, entre otras cosas, si nos cae bien él que nos pide algo, nos da pena rechazarlo.

El efecto de aceptar demasiados compromisos es que rebasamos nuestra capacidad de terminarlos durante el tiempo que tenemos destinado al trabajo. En consecuencia, para cumplir con todos, tenemos que “robar” el tiempo que pensábamos dedicar a otras cosas. Nos quedamos más tiempo en el trabajo o lo llevamos a casa.

El tiempo “robado” crece porque al tener que cumplir con muchos compromisos a la vez empezamos a brincar de uno a otro para avanzar en todos. Pero nuestras cabezas, a diferencia de los sistemas operativos, no tienen la velocidad de cambiar de una “aplicación” a otra. Necesitamos tiempo para recordar de qué se trataba para reanudar un trabajo interrumpido.

El efecto lateral del trabajar bajo presión de tiempo es que los resultados pueden ser de menor calidad, nos falta tiempo para revisarlos y, además, nos sentimos inseguros al entregarlos. Esto nos puede poner de malas en vez de sentir la satisfacción de hacer las cosas bien.

Otro riesgo es que de plano no vamos a poder cumplir a tiempo con tantos compromisos. Esto resulta en retrasos, que siempre tienen un costo (cost of delay), ya sea para nosotros mismos o para quienes esperan a nuestros resultados.

Dependencias desconocidas

En nuestra área encontramos por lo menos tres tipos de dependencias:

Arquitectónicas (en hardware y software): cuando un cambio puede afectar a otras partes.
De expertiz: cuando lo que tenemos que hacer depende del conocimiento específico de otra persona.
De actividades: cuando no podemos avanzar hasta que otra persona termine su trabajo.

Si no conocemos las dependencias en estos tres casos, el “robo” del tiempo es muy claro. Si cambiamos algo en un componente, o en una base de datos, sin entender el efecto en otros elementos, el tiempo extra que se va a necesitar para corregirlo es inevitable.

Si tenemos que esperar “papando moscas” a que un experto tenga tiempo para auxiliarnos en alguna tarea, también estamos perdiendo el tiempo. Lo mismo aplica en el caso de las dependencias desconocidas de las actividades entre los miembros de un equipo o con sus clientes.

Trabajo no planificado

Nos pasa frecuentemente que cuando estamos haciendo algo planificado nos tocan la puerta o hablan por teléfono y nos interrumpen. Si tenemos suerte, la interrupción es corta y podemos regresar a nuestro quehacer principal. En este caso el “robo” de tiempo es poquito, pero si sucede varias veces durante el día, ya puede ser considerable. ¿Pero qué sucede cuando el que interrumpe es nuestro jefe y nos manda a atender un “bomberazo”? Aquí la interrupción por lo general es muy larga y desplaza por mucho más tiempo el trabajo que íbamos realizando. Aunque este tipo de interrupciones para hacer trabajo no planificado es inevitable, hay que tenerlo en cuenta cuando hacemos estimaciones.

Prioridades en conflicto

¿Qué pasa cuando no tenemos claridad sobre las prioridades de las cosas que tenemos que hacer? Yo, casi siempre, de mi lista de pendientes escojo primero los que requieren de poco esfuerzo y los que son más complejos los pospongo, lo que termina en que cuando me pongo a trabajar en lo importante ya estoy cansada y se me hizo tarde.

Y ¿qué pasa en los equipos de desarrollo cuando las prioridades del cliente no se transmiten claramente al equipo? Si el equipo siente incertidumbre sobre qué es lo que tiene mayor prioridad se pone a trabajar en lo que le parezca y esto puede llevar al conflicto con el cliente. Pero además, sucede que lo que es de mayor prioridad para uno no lo es para el otro, lo que causa conflictos dentro del propio equipo y la pérdida de tiempo en cosas que no son de relevancia en un momento dado.

Trabajo descuidado

Un ejemplo del trabajo descuidado es preferir mantener un sistema obsoleto, incrementando su deuda técnica, que lanzarse con el desarrollo de un sistema nuevo con tecnología reciente.

Hay que tener cuidado con la deuda técnica invisible que se acumula mientras los equipos se dedican a atender prioridades a corto plazo.

Los sistemas con deuda técnica tarde o temprano explotan causando daños mucho más costosos que la inversión requerida para mejorar o sustituirlos a tiempo. Estos daños para repararse requieren de tiempo —otro “robo” que puede ser a gran escala.

Dos ejemplos más de trabajos descuidados son los que esperan retroalimentación, que nunca llega, o los considerados importantes pero no urgentes.

También, hay otra categoría del trabajo descuidado que se conoce como proyectos Zombie. Por lo general estos proyectos son internos, considerados de bajo valor, que apenas están “vivos”. Andan buscando quien los “apapache”, pero no encuentran “amor”. Se están muriendo de “hambre” por falta de dinero, recursos y personas a pesar de que la organización los necesita. Un ejemplo de estos proyectos es cuando se requiere actualizar las herramientas de desarrollo pero no hay quien se dedique a seleccionarlos y probarlos.

Conclusión

Me imagino que les parecieron muy familiares estos “ladrones” de tiempo. En su mayoría son inevitables. Lo que propone la autora del libro es que para aminorar sus efectos hagamos visible todo nuestro trabajo pendiente y en progreso, para que no se nos olvide. También, que tengamos más conciencia al aceptar nuevos compromisos, entender y analizar las dependencias, manejar mejor las interrupciones, asegurarse de las prioridades y no descuidar el trabajo que tarde o temprano habrá que hacer. Yo me llevo estos consejos para mi trabajo académico y espero que a ustedes también les haga click.

Referencias

1. Dominica DeGrandis, “Making work visible, Exposing time theft to optimize work & flow”, IT Revolution Press, 2017.

Bio

La Dra. Hanna Oktaba (@hannaoktaba) es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

¿Por qué mi Equipo Tiene Broncas?

ana2lp — Wed, 03 May 2017 06:18:34 +0000

¿Por qué mi Equipo Tiene Broncas?

ana2lp Wed, 05/03/2017 - 01:18

Publicado en

SG #54

Tejiendo nuestra red

Autor

Hanna Oktaba

Observando los equipos de mis alumnos, escuchando quejas de los que ya están trabajando y por experiencia propia, coordinando el equipo de Renovación de MoProSoft (si, dio efecto mi convocatoria de SG no.53) me he dado cuenta que convertir un grupo de personas en un equipo productivo y contento no son “enchiladas”. Ya los agilistas en su manifiesto de 2001 nos advirtieron que hay que valorar más a los “individuos e interacciones sobre procesos y herramientas”. Esta advertencia fue muy importante, surgieron varias propuestas de cómo empoderar a los miembros del equipo, con SCRUM como ejemplo más destacado.

Sin embargo, todavía nos falta entender cómo evolucionan los equipos. Para eso empezamos con mi alumna de doctorado Sandra Ramírez esculcar en Ciencias Sociales. La primera sorpresa fue que hay una diferencia entre un grupo de personas, un grupo de trabajo y un equipo!!! Según [1] y [2]:

Un grupo: son 3 o más personas que interactúan entre sí para realizar un número de tareas y lograr un conjunto de objetivos comunes ( para mi, son burócratas).
Un grupo de trabajo: tiene miembros que quieren crear el entendimiento común de los objetivos y crear una estructura para lograrlos. (para mi, son empresarios).
Un equipo: es un grupo de trabajo que tiene objetivos comunes y métodos efectivos para lograrlos (para mi, así deberían ser los equipos de desarrollo de software).

Es decir, no es suficiente juntar unas cuantas personas y decirles cuales son los objetivos del proyecto para que de inmediato se conviertan en un equipo productivo.

Buscando un poco más encontramos que ya en 1965 Tuckman [3] publicó un modelo de desarrollo, no de software sino de equipos. En este modelo se identifican cuatro fases por las que atraviesan los grupos en su desarrollo:

1. Forming (formación)

En esta etapa el grupo apenas se integró, la gente empieza a conocerse, no tienen muy claro el objetivo del trabajo ni sus roles. Los individuos tratan de transmitir a otros sus habilidades, pero todavía no tienen claro su papel en el equipo y se sienten inseguros. Por lo tanto todos dependen mucho de las instrucciones del líder.

2. Storming (enfrentamiento)

Los miembros del equipo luchan entre sí para posicionarse dentro del equipo. Tratan de establecer por sí mismos relaciones con otros miembros del equipo y con el líder. Se forman pandillas y agrupaciones y se pueden dar luchas de poder. El líder actúa como coach.

Fase 3: Norming (normalización)

Los conflictos se reducen y los miembros empiezan a reconocer que pertenecen a un grupo. Se forman acuerdos y consensos dentro del equipo bajo la batuta del líder. Roles y responsabilidades son claros y aceptados. El equipo lleva a cabo reuniones para discutir y desarrollar sus procesos y su forma de trabajo. El líder es respetado por el equipo y parte del liderazgo es compartido por el equipo. El líder actúa como facilitador.

Fase 4: Performing (desempeño)

El equipo trabaja con un buen rendimiento y pocos conflictos, está preparado para tomar decisiones sin la necesidad de la participación del líder. El enfoque está en lograr resultados, el equipo tiene un alto grado de autonomía. Cuando ocurren desacuerdos el equipo es capaz de resolverlos. También, el equipo realiza los cambios al proceso y a la estructura cuando sea necesario. El equipo no necesita ser instruido o asistido por el líder. El líder delega.

Figura 1. Modelo de Tuckman

Algunos dicen que estas etapas de desarrollo de equipos se parecen a las etapas que pasamos los seres humanos en nuestras vidas: Forming –> Infancia, Storming –> Adolescencia, Norming –> Adultez y Performing –> Madurez. Esta similitud me encanta, primero, porque es muy fácil de acordarse y dos porque como ya estoy en la madurez, me gusta pensar que todavía tengo buen “performing” :).

Este modelo me ayudó a entender una de las razones por la que MoProSoft y otros modelos no siempre fueron adoptados con éxito. Sospecho que sus organizaciones estaban en la etapa de adolescencia y todavía no les caía el veinte que para ser productivos necesitaban pasar a la fase de normalización.

Otra cosa que este modelo me ayudó a entender es porqué los equipos no pueden ser muy productivos desde el primer día que se junten. Por más que seleccionemos buenos expertos técnicos, el equipo tendrá que pasar por las etapas de la infancia y la adolescencia antes de volverse adultos, léase productivos. La Fig.1 muestra, además, cómo en la etapa de adolescencia el equipo se vuelve menos efectivo como consecuencia de sus luchas internas; seguro que lo han observado en sus equipos favoritos de fútbol cuando se integran nuevos jugadores.

Y ustedes en sus equipos de trabajo, ¿con cuál etapa se identifican? Aparentemente, mientras más tiempo trabajan juntos deberían ya estar por lo menos en la etapa de adultez. Pero muchos me van a contestar: es que seguimos con las broncas de la adolescencia :(. Entonces analicen las habilidades de su líder. En las primeras dos etapas su papel es primordial.

Un buen líder tiene que:

Conocer muy bien los objetivos del proyecto y saber transmitirlo al equipo.
Fungir como una autoridad y capacitador en la parte técnica y en las formas de trabajar.
Identificar habilidades de cada persona para poder coordinar el trabajo adecuadamente y generar la confianza mutua.
Ser honesto y justo.
Ser un buen psicólogo para manejar los estados de ánimo de las personas y saber cuándo “apapacharlas” y cuándo “jalarles las orejas”, siempre con respeto.
Asegurar las condiciones de trabajo adecuadas.

En pocas palabras, un líder tiene que ser un coach, un entrenador, que sobre todo en las primeras etapas de formación y conflicto, ayude a un grupo de personas convertirse en un equipo. Si no me creen, analicen las trayectorias de los entrenadores de fútbol.

Referencias

J. Keyton, “Communicating in groups: Building relationships for group effectiveness”, New York, McGraw-Hill, 2002.
S.Wheelan & J. Hochberger, “Validation studies of the group development questionnaire”, Small Group Research, vol. 27, no. 1, pp. 143-170, 1996.
B. W. Tuckman, "Developmental sequence in small groups". Psychological Bulletin. 63 (6), 1965.

MoProSoft Revive

sg — Mon, 12 Dec 2016 19:34:19 +0000

MoProSoft Revive

sg Mon, 12/12/2016 - 13:34

Publicado en

SG #53

Tejiendo nuestra red

Autor

Hanna Oktaba

No sé qué está pasando pero en las últimas semanas ha revivido el interés por MoProSoft. ResearchGate me está felicitando semanalmente por tener más de 20 lecturas del documento de MoProSoft 1.3 y los lectores no son nada más de México, lo leen en América Latina, en EU y hasta en la India. Los Institutos Tecnológicos de la república me piden conferencias sobre este tema y otros peregrinan de Lázaro Cárdenas a la Ciudad de México para pedirme una plática en la Facultad de Ciencias. Un maestro de UPIICSA del IPN trajo a cinco alumnos de primer semestre para que me entrevistaran sobre MoProSoft. Una de mis amigas consultoras, que normalmente da capacitaciones sobre CMMI o Project Management, me comentó sorprendida que una institución gubernamental le pidió un curso de qué creen – de MoProSoft. Y para derramar el vaso de mi felicidad un joven, @Netozack, mandó un tuit: “Revisando MoProsoft, muy interesante conocer este estándar @hannaoktaba, es esencial para el desarrollo de software en México el tenerlo”.

No lo puedo creer. ¿Tenían que pasar 14 años para que se apreciara lo que hemos creado en México? Pero más vale tarde que nunca ☺. Para las nuevas generaciones, que todavía no lo conocen, decidí hacer un pequeño recorrido por el modelo, empezando con la anécdota de su creación.

En agosto de 2002 la Secretaría de Economía dio luz verde a la AMCIS (Asociación Mexicana para la Calidad en Ingeniería de Software) para crear un modelo de procesos que ayudaría elevar el nivel de capacidades a la incipiente industria de software mexicana. Para un sábado de finales de agosto, como presidenta de la AMCIS convoque a la primera reunión a todos los interesados en el proyecto. Y ¿qué creen? ¡Llegaron puras mujeres! En esta primera reunión, bajo la batuta de Gloria Quintanilla, definimos la estructura de procesos indispensables para organizar bien el trabajo de una empresa de software (ver fig. 1). Las novedades principales con respecto a otros modelos, como CMMI o ISO/IEC12207, fue la inclusión explícita del proceso de Gestión de Negocio y la integración de los procesos entre sí. Otra innovación fue la definición del patrón (plantilla) para documentar los procesos, que tiene muchos más elementos que no van a encontrar en ningún otro modelo.

Figura 1. Procesos de MoProSoft.

En la siguiente reunión se incorporaron tres compañeros y en total participamos 8 mujeres y 3 hombres. Todos trabajaron voluntariamente y en sus ratos libres, nos reuníamos presencialmente los sábados (no existía skype, ni hangouts), el intercambio de documentos se hacía por correo electrónico (no existía dropbox, ni drive) y la primera versión de MOPRIS (Modelo de Procesos para la Industria de Software – así se llamaba en su primera versión) estuvo lista a finales de diciembre de 2002. Tiempo record, que yo sepa, para definir modelo de procesos!!!! Luego, gracias a Laura Almada Vélez, lo rebautizamos como MoProSoft y este nombre nos gustó a todos, incluyendo a la Secretaría de Economía, que luego bautizó a su programa para el apoyo a la industria de software como PROSOFT.

Para definir el contenido de los procesos los colaboradores escogieron uno en función de su conocimiento y experiencia. Así, aunque usted no lo crea, Mara Ruvalcaba – la directora de operaciones de la revista SG, fue responsable por el contenido del proceso de Gestión de Negocio. Los que lo han implementado bien reconocen, que tener un plan estratégico para la empresa, los objetivos y metas cuantitativas del negocio y, controlarlos es una aportación muy importante que incentiva a los directivos a ser más visionarios pero también obliga a ser más disciplinados.

Angélica Sú armó el contenido del proceso de Gestión de Procesos. Este proceso ayuda a definir las formas de trabajar que necesita la organización en función de los objetivos del negocio, controla su aplicación y las mejoras. Es el mecanismo a través del cual la organización acuerda cómo quiere trabajar, por ejemplo introduciendo prácticas ágiles, y les ayuda a verificar si realmente estas prácticas les sirven al negocio.

Francisco López Lira se ocupó del proceso de Gestión de Proyectos que abarca desde la búsqueda de proyectos nuevos (ventas) hasta el control cuantitativo y cualitativo de los proyectos ya contratados. Este proceso tiene un valor particular para las empresas pequeñas para poder controlar su crecimiento cuando les llueven proyectos.

Alfonso Martínez fue responsable por la integración y coherencia del proceso de Gestión de Recursos. Este proceso es peculiar, porque tiene tres subprocesos enfocados en diferentes tipos de recursos. El cuidado de recursos humanos quedó plasmado en el subproceso Recursos Humanos y Ambiente de Trabajo a cargo de Maria Elena Rivera y el subproceso de Bienes, Servicios e Infraestructura nos ayudó a definir Miguel Ángel Flores. Otra aportación de MoProSoft a los modelos existentes fue la inclusión del tercer tipo de recursos que hay que cuidar en este tipo de empresas. Lo llamamos el subproceso de Conocimiento de la Organización, a cargo de Yolanda Fernández, el cual se refiere a la creación, resguardo y mantenimiento de la Base de Conocimiento de la organización. En una organización de desarrollo de software tener acceso al conocimiento generado es fundamental.

Finalmente, María Julia Orozco incorporó prácticas básicas en el proceso de Administración de Proyectos Específicos y yo con Claudia Alquicira fuimos responsables por el contenido del proceso de Desarrollo y Mantenimiento del Software. Los dos procesos conforman la base para las actividades operativas de una empresa de software. La redacción de partes generales y la revisión de la consistencia del modelo estuvo a cargo de Claudia Alquicira y su servidora.

Durante los 14 años MoProSoft ha transitado por varios caminos. Desde volverse norma mexicana NMX-059-NYCE en 2005 a ser reconocido a nivel internacional como estándar ISO/IEC 29110 para Very Small Entities. Fue probado en empresas españolas, colombianas, brasileñas, peruanas, chilenas, ecuatorianas y uruguayas gracias a los proyectos COMPETISOFT y RELAIS. En México más de 500 empresas lo han implementado con mayor o menor éxito y como ISO/IEC 29110 se está implementando en Canadá, Tailandia, Irlanda entre otros. Ni hablar de Japón cuyo representante en el ISO/IEC me regaló un ejemplar de su guía para los procesos de operación en japonés :).

Convocatoria para renovar MoProSoft

En estos 14 años se han popularizado nuevas estrategias de desarrollo como Agile+Lean y DevOps; también han crecido nuevas generaciones de desarrolladores para las cuales leer textos largos con tablitas de “word” es aburridísimo. Creo que MoProSoft tiene muchas ideas todavía valiosas pero ya amerita una “manita de gato” y una forma de presentación más moderna.

Por lo tanto, como hace 14 años, lanzo un llamado a acción para los que tienen ideas y ganas de participar en la renovación de MoProSoft. Interesad@s favor de comunicarse a hanna.oktaba@ciencias.unam.mx , también se aceptan hombres :).

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. @hannaoktaba

Pioneras en la Preocupación por la Calidad en Ingeniería de Software

sg — Wed, 12 Oct 2016 04:50:15 +0000

Pioneras en la Preocupación por la Calidad en Ingeniería de Software

sg Tue, 10/11/2016 - 23:50

Publicado en

SG #52

Tejiendo nuestra red

Autor

Hanna Oktaba

Hace unos días mi amiga Gloria Quintanilla me mandó una foto vieja encontrada en el baúl de su mamá. Esta foto ha despertado muchos recuerdos que quiero compartir con ustedes por dos razones: la primera es que se trata de una foto histórica de 1997, que presenta al grupo que fue uno de los pioneros al hacer algo por la calidad de software en México. La segunda razón es que son puras mujeres.

En aquel entonces tuve la oportunidad de disfrutar por primera vez el año sabático en la UNAM. Normalmente para pasar el año sabático los académicos escogen a una universidad para colaborar con otros investigadores. Pero en mi informe de sabático encuentro que efectivamente tuve una estancia académica en el Departamento de Electrónica del Politécnico de Milán (junio 1997 – julio 1997). Durante la cual me dediqué a estudiar el concepto de Proceso de Software y sus distintas formas de modelado. En particular, estudié el modelo de Personal Software Process de Watts Humphrey, que en ese entonces era casi desconocido en México.

Sin embargo, el resto de mi sabático (agosto 1997 – mayo 1998) tuve una estancia de colaboración en la empresa Tecnosys, en la ciudad de México, durante ese tiempo:

- Participé en la definición y la implantación del sistema de calidad en la empresa el cual la llevó a la obtención del certificado de ISO9001 en diciembre de 1997.

- Ofrecí dos cursos de capacitación para el personal de la empresa sobre el “Panorama de Tecnología Orientada a Objetos” y “Proceso Personal de Software”.

- Desarrollé una propuesta del programa de métricas para Tecnosys.

- Participé en la definición del modelo conceptual de una biblioteca de componentes reutilizables para la empresa.

- Apoyé a la gerente de calidad en la coordinación de su grupo de trabajo.

Gloria, que aparece en la foto a mi lado izquierdo, fue justamente esa gerente de calidad que tuvo la idea de invitarme a ayudarle a implementar el sistema de calidad basado en ISO 9001 en una empresa de desarrollo de software recién comprada por IBM de México, cuyo desafío adicional fue adoptar los procesos de desarrollo de la propia IBM. El reto fue muy grande. Nuestro equipo de trabajo lo completaban Angélica Su Ramos y Cecilia Montero Mejía (primera y segunda de la izquierda en la foto), ambas fueron mis ex alumnas de la Maestría en Ciencias de la Computación de la UNAM, y Mariana Pérez-Vargas de Tecnosys (de mi lado derecho en la foto). También, incorporamos a mi ex alumno de maestría Carlos Pérez Escobar, que no aparece en la foto, para no desdeñar la visión masculina ;) Una proporción parecida se repitió en el equipo que definió MoProSoft: fuimos ocho mujeres y tres hombres.

Para documentar el sistema de calidad con todos los elementos requeridos, Gloria encontró una herramienta irlandesa llamada Aimware, pionera en el mercado. Invitamos a Eamon McGuiness, el dueño de la empresa, para que nos convenciera y capacitara en su uso.

Contamos con cinco meses para “traducir” los requisitos de ISO 9001:1995, enfocados en lenguaje de empresas manufactureras, a los conceptos de los proyectos de desarrollo de software. Lo más difícil, que se me grabó en la memoria, era entender que en la manufactura hay que cuidar la calidad de cada copia producida a partir de un prototipo del producto, pero en el desarrollo de software lo importante es cuidar la calidad durante el desarrollo del prototipo, porque las copias salen con la misma calidad sin problema.

Cuando ya teníamos definidos todos los elementos del sistema de calidad con sus políticas, procesos y procedimientos documentados en Aimware, empezamos a buscar un auditor para revisar nuestra propuesta. La tarea no fue fácil porque no se contaba con experiencias de auditorías de ISO 9001 en las empresas de desarrollo de software (donde los productos son intangibles) y menos con la documentación en forma electrónica —todo se documentaba en papel. La que aparece segunda de la derecha en la foto es Margarita Santos, la única auditora que aceptó el reto. Apreciamos mucho su apertura para comprender las particularidades del desarrollo de software, como por ejemplo, que los insumos provienen del conocimiento humano, y su aceptación de que el manual de calidad estuviera albergado en un sistema de software.

Toda esta aventura se terminó con una auditoría exitosa en diciembre de 1997 y dio pie a que en el año siguiente con esta base trabajáramos en la adopción de SW-CMM nivel 2 y 3. Como efecto lateral, desde septiembre de 1997 en Tecnosys empezamos reuniones mensuales, de lo que llamamos “Círculo de Calidad de Software”, en las cuales invitábamos a todos los interesados en temas de calidad en ingeniería de software. En las reuniones se hacían presentaciones de los modelos y estándares como CMM, ISO/IEC 15504, RUP entre otros. Su éxito fue tal que en 1999 fundamos la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS).

Pero, ¿qué ha pasado con las mujeres guapas que aparecen en la foto?, además de haber logrado varios éxitos profesionales y contribuir con un granito de arena en temas de calidad para la industria de TI en México, son felices madres de familia que han logrado conjuntar la vida profesional con la familiar. Gloria tuvo una participación crucial en el diseño de MoProSoft y MAAGTIC y es consultora en dirección de proyectos, planeación estratégica y gobierno para resultados, con una experiencia muy importante para el gobierno de Ecuador. Mariana es SCAMPI Lead Appraiser y socia fundadora de la consultora Avantare, que es líder en el mercado mexicano bajo su dirección. Angélica es coautora de MoProSoft y consultora experta en modelos y estándares de TI, actualmente está dirigiendo proyectos de TI dentro del sector financiero. Cecilia fue la primera evaluadora de América Latina reconocida por el Software Engineering Institute como Lead Appraiser de SW-CMM, posteriormente se convirtió en la primera instructora de CMMI certificada en nuestro país. Actualmente imparte cursos en México y varios países de habla hispana y también se dedica a la consultoría.

A manera de dedicatoria a nuevas generaciones de mujeres involucradas en TI quiero decirles que seguro están igual o mejor preparadas que nosotras en su momento. El avance en la tecnología y las opciones de acceso al conocimiento y al emprendimiento son oportunidades que sin duda las mujeres jóvenes deben aprovechar para llevar adelante iniciativas, asumir el papel de liderazgo a nivel profesional y, a la par, cumplir sus sueños personales.

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. @hannaoktaba

Dime qué Desayunaste y Te Diré qué tan Productivo Estarás Hoy

sg — Fri, 08 Jul 2016 05:17:53 +0000

Dime qué Desayunaste y Te Diré qué tan Productivo Estarás Hoy

sg Fri, 07/08/2016 - 00:17

Publicado en

SG #51

Tejiendo nuestra red

Autor

Hanna Oktaba

Recientemente me topé en la red con un artículo que, primero me llamó la atención por su título: “Productividad Ágil: Voluntad con enfoque de neurociencias” [1], y luego me cautivó por su contenido.

El enfoque al tema de productividad en Ingeniería de Software, abordado de manera similar como lo hacen las industrias “tangibles”, siempre me ha parecido inadecuado (con todo respeto para mis colegas “creyentes fervientes” en PSP, TSP y CMMI).

La forma en la que las empresas miden la productividad, es a través de un cálculo en el que se realiza una comparación entre los insumos y los productos, donde la eficiencia es lo que representa el costo por unidad de cada producto. [2]

El problema que percibo en la industria de software tiene dos aspectos: por un lado, producir software es un trabajo donde los insumos y la maquinaria se encuentran en el cerebro de un humano y los productos son abstractos, por lo tanto es una industria de lo intangible. Por otro lado, no se ha llegado a definir una unidad del tamaño de software de manera universalmente aceptada. En la prehistoria empezamos con líneas de código (LOCs), luego llegaron puntos por función (FPs), siguieron puntos por casos de uso (que nunca se estandarizaron) y ahora tenemos puntos COSMIC, que podrían ser buenos candidatos por ser estándar ISO, pero dependerá de la aceptación por parte de la industria. Sin la misma medida del tamaño, las definiciones de la productividad son incomparables. Para los que gustan de los albures: en la Ingeniería de Software el tamaño sí importa :( .

¿Y qué tiene que ver la voluntad con todo esto?

En el artículo mencionado al inicio, la autora nos explica que la fuerza de voluntad es la que nos permite tomar decisiones para hacer algo, a veces difícil y no necesariamente muy agradable, pero que al final nos traerá una gratificación.

Díganme, si participar en un proyecto de software no es hacer algo a veces difícil y no necesariamente muy agradable, pero que finalmente algún día nos pagarán. Pero si alguien, como yo, pensaba que la fuerza de voluntad dependía en gran medida de la “zanahoria y el látigo”, estaba muy equivocada. Para tener fuerza de voluntad necesitamos tener suficiente lisina (un aminoácido) que nutre nuestra capa prefrontal del cerebro (figura 1). Y, ¿de dónde viene la lisina? De las proteínas que comemos. Así que, si desayunaste huevitos con frijolitos quédate tranquilo, vas a ser muy productivo, pero si solo comiste pan dulce con café, tu concentración en el trabajo va ser muy cortita :( .

El consejo no es solamente desayunar y comer proteínas para ser productivo. La autora nos da unas pistas de cómo ahorrar la lisina para poder trabajar concentrados por más tiempo durante un día:

Crear hábitos.
Usar rituales.
Trabajar en modo fluido.

Un hábito es algo que sabemos, podemos y queremos hacer. Ir a bañarse después de levantarse es un hábito que sabemos cómo hacerlo, si tenemos regadera, podemos hacerlo y si hay agua caliente, queremos hacerlo :) . La gratificación al final también se siente. Los hábitos requieren muy poca fuerza de voluntad, porque nuestro cerebro reconoce rápido que es algo habitual y lo hacemos sin mucho esfuerzo. Lo malo de adquirir nuevos hábitos es que para que se nos “peguen” necesitan repetirse diariamente por lo menos ¡70 días! Con este dato entendí porque mis propósitos de año nuevo se vuelven tan irreales.

Un ritual es una ceremonia o acción realizada como costumbre. Los rituales nos dotan de energía. Uno de los rituales más bonitos que he encontrado en México es el Día de Muertos, aunque cuando por primera vez vi en el altar del posgrado de la UNAM una calaverita de azúcar con mi nombre en la frente, me asusté. Los rituales y los hábitos son como caminos bien trazados en nuestro cerebro, que no cuesta esfuerzo volver a recorrerlos.

Un modo fluido de trabajo es cuando estás concentrado en una tarea única, interesante, compleja, pero no demasiado, desconectado de tu entorno y en el pico de tu concentración. La resistencia (física) y la paciencia (mental) también ayudan. El modo fluido de trabajar se dificulta cuando la tarea, que tenemos que hacer, no es ni interesante ni compleja, en este caso nos aburrimos rápido y buscamos distracciones para no hacerla. Otro extremo es cuando la tarea es tal vez interesante, pero tan compleja que no sabemos ni cómo empezar. En este caso nos angustiamos, las cosas no salen y podemos caer en el estrés. El estado de estrés (figura 2) nos lleva a perder el foco en el trabajo, lo que causa la mala calidad de los resultados, cuyos defectos tenemos que corregir, lo que nos causa mayor estrés. Y de la gratificación ni hablar, puros regaños. ¿Quién no ha vivido este círculo vicioso?

¿Cómo esto se relaciona con el trabajo de desarrollo de software?

Hábitos

En el caso de las prácticas SCRUM, las reuniones diarias realizadas siempre al inicio del día, a la misma hora, en el mismo lugar, con asistencia de todo el equipo y con las mismas preguntas es un hábito que, bien llevado a cabo, carga a todos con energía necesaria para empezar con mucha voluntad el trabajo (suponiendo que todos desayunaron proteínas :) ). Otro ejemplo de hábito es cuando uno, al terminar una tarea, revisa el resultado antes de entregarlo y hace todo lo que se pide para que otros se enteren que ya la había terminado (por ejemplo, mover la tarjeta en el tablero y/o reportar las horas dedicadas). Avisar que uno había terminado bien una tarea es gratificante ¿verdad?

Rituales

No se lo digan a nadie, pero todas las buenas prácticas de los modelos, estándares y libros de Ingeniería de Software son rituales. Qué tal el ritual del Sprint de SCRUM. Ya desde el nombre, carrera corta de atletismo, suena a misterio. Inicia con la reunión de la planificación a dos tiempos en la que participa activamente el equipo de desarrollo y el (igual de misterioso) Product Owner. El sprint tiene una duración corta de entre 2 a 4 semanas, que para el desarrollo de proyectos de software es efectivamente una carrera corta, y termina en la revisión de software con el Product Owner y en la retrospectiva del equipo. Al final del sprint, si todo salió bien, la satisfacción del equipo debería recargar sus energías para aguantar la siguiente carrera, igual de corta, que empieza la semana siguiente. Ni toman en cuenta, que en el atletismo los cuatro sprints de 100 metros se hacen por relevos :) .

Otros ejemplos de rituales son las diferentes técnicas para comprender y especificar a los requerimientos como los casos de uso o historias de usuario. Empiezan con el peregrinar para entrevistar a los diferentes representantes del cliente para comprender qué diablos quieren y qué significa lo que quieren. Continúan con los intentos de expresarlo de alguna forma, que sea de utilidad posterior para guiar al desarrollo. Luego sigue la batalla con los involucrados por la confirmación de que lo que se expresó como requerimiento ellos lo entienden y quieren que sea implementado. Cuando termina este ritual, los desarrolladores se llenan de energía porque, por un rato, piensan que allí terminó la batalla por comprender los requerimientos. ¡Qué ingenuos!

La mala noticia es que en estos rituales los que ahorran lisina son solo aquellos que los han repetido muchas veces, es decir, ya se volvieron sus hábitos. Los que son novatos van a sufrir.

Modo fluido de trabajo

Para trabajar de esta manera en el desarrollo de software, es indispensable que el reto que tenemos que atacar sea acorde con nuestros conocimientos y habilidades. Si se deja una tarea habitual como por ejemplo, documentar un caso de uso o una historia de usuario a un principiante que apenas fue capacitado (o mintió que sabía como hacerlo), se va a sentir muy angustiado y no va a poder hacerlo bien. O al contrario, si dejamos a un analista experimentado una tarea de documentar el requerimiento de “iniciar la sesión”, se va a sentir subutilizado. En ambos casos no van a sentir la satisfacción de su trabajo y la productividad va estar por los suelos.

El consejo final es: usa rituales (procesos) para iniciar el hábito de trabajar con fluidez. Y come proteínas :) .

PD. Esta es mi columna número 50 para la revista Software Guru. Durante más de 11 años repito un ritual de escribirla, que ya se volvió mi hábito y lo hago de manera fluida. Cuando la releo ya publicada me siento muy bien :) .

Referencias

A. Obukhova. “Agile Productivity: Willpower and the Neuroscience Approach”. http://swgu.ru/rg
http://definicion.de/productividad

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. @hannaoktaba

Propósito 2016: Organicémonos un Poco Más

sg — Fri, 04 Mar 2016 09:35:34 +0000

Propósito 2016: Organicémonos un Poco Más

sg Fri, 03/04/2016 - 03:35

Publicado en

SG #50

Tejiendo nuestra red

Autor

Hanna Oktaba

Les quiero comentar sobre algunas iniciativas de organización de la comunidad de la Computación y, en particular, de Ingeniería de Software en las cuales me tocó participar como miembro fundador en los últimos años.

Red Universitaria de Colaboración DE Ingeniería de Software y Base de Datos (RedIS&BD)

En mayo del 2006 se constituyó en la UNAM la Red Universitaria de Colaboración en Ingeniería de Software y Base de Datos (RedIs&BD), coordinada por Guadalupe Ibargüengoitia González de la Facultad de Ciencias. Su misión es integrar a un grupo de universitarios expertos para conformar una red de colaboración, intercambio y difusión del desarrollo y aplicación de software de calidad, para beneficio de la Institución. Durante 10 años la actividad de la red se ha concentrado en la organización de seminarios mensuales y talleres, así como encuentros universitarios; el último organizado en octubre de 2015, logró conjuntar interesados no solo de la UNAM sino de otras instituciones académicas y privadas. Más información en http://www.redisybd.unam.mx

Red Temática Mexicana de la Ingeniería de Software (REDMIS)

Es un proyecto surgido de la Convocatoria de Registro y Estructuración de Redes Temáticas CONACYT 2014. Su objetivo es integrar una red de especialistas en Ingeniería de Software, agrupando a los investigadores y académicos así como a los empresarios con intereses comunes en la disciplina, con el fin de generar conocimiento científico, generar buenas prácticas de manera colegiada, elaborar y ejecutar propuestas que apoyen la educación en el área, así como unir esfuerzos con la industria para apoyar su competitividad en el ramo del desarrollo de software. El responsable técnico de REDMIS es Reyes Juárez Ramírez de la Universidad Autónoma de Baja California y en su Consejo Técnico se encuentran académicos de la UNAM, UPSLP, UAM-I, UTM, ITH, UADY y UV. La comunidad está organizada por nodos ubicados en diversos lugares del territorio mexicano. La principal actividad de la REDMIS es dar continuidad a las reuniones académicas de Ingeniería de Software realizadas desde el año 1997. La próxima es la reunión de CONISOFT16 que se llevará a cabo en abril en la UPAEP, Puebla (http://redmis2016.com.mx). Más información en http://redmis.com.mx

Academia Mexicana de Computación (AMEXCOMP)

Tiene como antecedente directo a la Red Mexicana de Investigación y Desarrollo en Computación (REMIDEC) fundada en 2008 para hacer un análisis de la computación desde su introducción a México, su estado actual y sus perspectivas, en el marco de la conmemoración de los 50 años de la computación en México. El Consejo de REMIDEC, integrado por los doctores Luis A. Pineda (IIMAS UNAM), Christian Lemaitre (UAM Cuajimalpa), Carlos Coello (CINVESTAV), Enrique Sucar (INAOE), Jesús Favela (CICESE) y Francisco Cantú (ITESM), planteó la posibilidad de crear la Academia Mexicana de Computación como una Asociación Civil. La constitución formal de la Academia Mexicana de Computación AC sucedió el 9 de enero de 2015 con 19 miembros fundadores (entre ellos su servidora como la única mujer). El objetivo principal de la Amexcomp es integrar a los investigadores, ingenieros, tecnólogos, innovadores, docentes y promotores de la computación más distinguidos de México en las distintas áreas de la computación para constituir un foro de excelencia de pensamiento computacional que sirva como referencia central de la ciencia y la tecnología computacional en México. En su primera asamblea general en diciembre de 2015 se crearon las secciones académicas por áreas de computación. Una de ellas es la de Ingeniería de Software de la cual soy coordinadora. Más información en http://amexcomp.mx

Como pueden ver hay un interés de la comunidad para organizarse con diferentes objetivos y alcances. Los lectores de esta columna están cordialmente invitados a unirse a ellas. Sin embargo, me parece que nos hace falta mucho esfuerzo de lograr la cohesión y colaboración para que la sociedad, la industria y el gobierno nos conozcan, aprecien y aprovechen. Tenemos que hacer más “ruido”. SG es uno de los pocos ejemplos en este sentido, que hay que apoyar y seguir.

Al principio de 2016 lancé por twitter una llamada “Que hagamos algo sensato para la industria de software en 2016! ¿Qué se les ocurre?”. Recibí una sola propuesta pero, en mi opinión muy buena, “Concretar la constitución de una comunidad de profesionales que fomente la generación de ideas aplicables a la realidad mexicana” de Alexandra Alatorre (@alex_alatorre). Sobre todo me gustó lo de “ideas aplicables a la realidad mexicana”. Creo que tenemos una fuente inagotable de oportunidades de innovación en serio, a través de la solución con TI de los problemas que padecemos. Pero la mayoría sueña con competir con Facebook o exportar a E.U.

Para la discusión constructiva y propuestas los invito a @hanna.oktaba.

Adiós ISO/IEC JTC1 SC7 WG24

sg — Fri, 25 Sep 2015 22:38:43 +0000

Adiós ISO/IEC JTC1 SC7 WG24

sg Fri, 09/25/2015 - 17:38

Publicado en

SG #48

Tejiendo nuestra red

Autor

Hanna Oktaba

La Organización Internacional de Estándares (ISO) y la Comisión Internacional Electrotécnica (IEC) son dos organismos dedicados a la definición de estándares internacionales. Los países miembros del grupo de ISO o IEC participan en el desarrollo de estándares internacionales a través de comités técnicos establecidos por cada una de estas organizaciones. Las propuestas de estándares internacionales que se reciben por los comités técnicos se envían a los representantes de cada país miembro para su revisión y aprobación. Una propuesta requiere tener una aprobación de al menos el 75% de los países miembros para ser publicada como estándar internacional.

Los estándares de Tecnología de Información (TI) al ser de interés mutuo entre ISO e IEC llevaron a la creación del comité técnico conjunto Joint Technical Comeetee (JTC1) dedicado al área de TI. Dentro de éste, se formó el subcomité SC7 designado para generación de estándares para la Ingeniería de Software y Sistemas. Este subcomité está organizado por grupos de trabajo Working Group (WG) que se encargan de un estándar en particular.

En junio de 2005 ISO/IEC JTC1 SC7 Software and System Engineering reconoció que sus estándares no fueron creados para los proyectos y organizaciones pequeñas, por lo que se creó un grupo de trabajo WG 24 específico para definir procesos de software para Very Small Entities (VSE), empresas, organizaciones o proyectos de 1-25 personas. Una de las primeras tareas del grupo fue averiguar si en algún país se hizo una propuesta dirigida a este sector.

Mi aventura con WG24

Un colega brasileño, Marcelo Pessoa, miembro de la WG24, quien conoció a MoProSoft, nos preguntó si podríamos enviar la norma mexicana para ser revisada por el grupo.

Coincidió que en octubre de 2005 presentamos a MoProSoft, EvalProSoft y los resultados de Pruebas Controladas en el Workshop of Process Improvement in Small Settings convocado por el Software Engineering Institute (SEI) en su sede de Pittsburgh. En este evento coincidimos con Claude Laporte de Canadá, editor del WG24, quien volvió a insistir en que presentáramos MoProSoft ante el grupo.

En mayo de 2006 la delegación de México asistió por primera vez en Tailandia a la reunión plenaria de ISO/IEC JTC1 SC7 Software and System Engineering para presentar MoProSoft ante el WG24. La presentación formal estuvo a cargo de Ana Isabel Vázquez Urbina y, para nuestra gran sorpresa, en votación unánime los representantes de Tailandia, EUA, India, Irlanda, Bélgica, Finlandia, Luxemburgo, Canadá, Nueva Zelanda y Corea decidieron tomar la norma mexicana como base para su trabajo. Jorge Palacios grabó un video que documenta este acontecimiento [1].

En la siguiente reunión de ISO/IEC JTC1 SC7 WG24 en Luxemburgo, en octubre de 2006, se tomó la decisión estratégica de presentar MoProSoft como estándar internacional en tres partes, es decir en grupos de procesos divididos por las tres capas del modelo. Cada una de las capas pertenecería al Grupo de Perfiles Genéricos. El primer perfil seleccionado para ser revisado y aprobado por WG24, llamado posteriormente como Perfil Básico, correspondió a los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software de la capa de Operación de MoProSoft.

El Perfil Básico fue una primera guía de procesos publicada dentro de la colección de documentos que conforman el nuevo estándar ISO/IEC 29110 dirigido a pequeñas organizaciones de desarrollo de software, cuyas partes se listan a continuación.

ISO/IEC 29110 Software engineering — Lifecycle profiles for Very Small Entities (VSEs):

Part 1: OverviewPart 2: Framework and taxonomy
Part 3: Assessment guide
Part 4-1: Profile Specifications: Generic profile group
Part 5-1-2: Management and engineering guide: Generic profile group: Basic profile

El Perfil Básico está incluido como Parte 5-1-2, el 1 significa que pertenece al primer grupo de perfiles genéricos, basados en MoProSoft, y el 2 es su número consecutivo. Las editoras de las partes 4-1 y 5-1-2 fueron Ana Isabel Vázquez, Blanca Gil, Claudia González y Hanna Oktaba.

El Perfil Básico se publicó en mayo de 2011 y para promover su uso entre las VSEs se solicitó al ISO su disponibilidad gratuita [2]. Un año más tarde se creó un perfil más elemental que el Básico, llamado Entry, el cual tiene asignado el número 1 dentro del grupo de perfiles genéricos y está dirigido a las organizaciones de reciente creación y el tamaño todavía más reducido. El estándar del Perfil Básico se recomienda para las organizaciones pequeñas que pueden ser empresas, departamentos o proyectos de hasta 25 personas. La guía se aplica en proyectos de desarrollo de software. El proyecto puede ser para cumplir un contrato externo o interno. El contrato interno no tiene que ser explícito entre el equipo del proyecto y sus clientes.

La diferencia entre los procesos de Perfil Básico y los de la capa de Operación de MoProSoft es mínima. Las organizaciones que tienen implementado MoProSoft a nivel 2 están cubriendo prácticamente el Perfil Básico. Este último, como está enfocado en las prácticas de un proyecto de software aislado, tiene algunas tareas que en MoProSoft se delegan a otros procesos. Por ejemplo, a falta de la base de conocimiento de la organización se propone el uso de un repositorio local del proyecto con ciertas reglas de su manejo. Algunos productos de trabajo sufrieron modificaciones a raíz de los comentarios del grupo y su apego a otros estándares ISO/IEC ya existentes, pero en general se parecen mucho.

Del grupo de perfiles genéricos basados en MoProSoft se está preparando el Perfil de Gestión Organizacional que incluirá los procesos de Gestión de Negocio y los de Gestión de Procesos, Recursos y Proyectos. Por supuesto estos procesos sufrirán modificaciones con respecto a sus versiones originales debido a las lecciones aprendidas de su uso y las aportaciones de la comunidad internacional.

Además, a la comunidad de sistemas les gustó el trabajo que hemos hecho y ya se ha publicado el Perfil Básico para el desarrollo de Sistemas. Los que trabajan el estándar de servicios también están viendo la necesidad de generar una versión para VSEs y los “agilistas” están preparando la modalidad ágil del Perfil Básico.

¿Por qué fue y sigue siendo importante la participación de México en la estandarización internacional?

Se logró ubicar a MoProSoft a la cabeza de los estándares internacionales para VSEs de la industria de software.
Se demostró que “lo hecho en México, está bien hecho” y no solo eso, sino que puede ser de calidad internacional.
Se ha logrado una aceptación de una norma mexicana como aporte al estándar internacional lo que demuestra que estamos a la vanguardia en la Ingeniería de Software

A los que todavía no conocen o no han entendido el valor de MoProSoft les invito a ver el video en el cual lo traté de explicar con manzanitas [3].

Mi despedida de WG24

Después de casi 10 años dedicados al trabajo en WG24 llegó la hora de decir adiós. Ustedes saben que tengo un“nuevo amor” que es mi “hija” más chiquita KUALI-BEH integrada al estándar ESSENCE de OMG, la cual requiere de mi mayor atención.

El WG24 me despidió con cariño y me llevo muy gratos recuerdos de este esfuerzo y muchas relaciones con gente muy apasionada. Les deseo que tengan éxito en esa apertura de los organismos de estandarización para facilitar los negocios también a los peques y no solo a los grandes. La Delegación Mexicana ante WG24 queda en las muy buenas manos de Claudia González, Blanca Gil y Salvador Sánchez.

Referencias

Miembros de WG24 opinando sobre MoProSoft. https://youtu.be/wu4vBfOkSVI
Perfil básico gratis: http://standards.iso.org/ittf/PubliclyAvailableStandards/c051153_ISO_IEC_29110-5-1-2_2011.zip
MoProSoft explicado: https://youtu.be/3Cn_2bKAV4Q

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. @hannaoktaba

KUALI- BEH como extensión de las alfas de ESENCIA (ESSENCE)

sg — Mon, 25 May 2015 06:11:13 +0000

KUALI- BEH como extensión de las alfas de ESENCIA (ESSENCE)

sg Mon, 05/25/2015 - 01:11

Publicado en

SG #47

Tejiendo nuestra red

Autor

Hanna Oktaba

En la columna anterior les platiqué sobre el concepto de las alfas de Esencia y su posible uso. Mientras se publicaba la revista, me enteré de que en noviembre del año pasado el estándar ESSENCE de OMG superó la prueba como beta 2 y, finalmente, fue publicado en su versión 1.0 [1] con KUALI-BEH incluido. En la sección 6 del documento se pueden apreciar los reconocimientos para la UNAM y todas las organizaciones y personas que nos han apoyado en esta aventura.

La historia de cómo se gestaba KUALI-BEH y como se “casó” con ESSENCE la pueden encontrar en mis columnas de los años entre 2012 y 2014. En esta ocasión les explicaré cual es el resultado final de la integración de KUALI-BEH a la Esencia.

KUALI-BEH (buen camino) es una propuesta de conceptos comunes para los proyectos de desarrollo de software, que permiten expresar los métodos y prácticas de las organizaciones, así como su ejecución durante los proyectos. Se compone de dos vistas (fig. 1): estática y operacional.

Figura 1. Vista estática y operacional de KUALI-BEH.

La vista estática permite a los ingenieros de software expresar sus formas de trabajar como métodos compuestos por prácticas, los cuales se resguardan como infraestructura del conocimiento de la organización.

La vista operacional se relaciona con la realización dinámica de proyectos. Proporciona a los equipos los mecanismos para ejecutar los métodos adaptando sus prácticas al contexto específico del proyecto y a las necesidades de los involucrados.

Entonces ¿cómo se integró KUALI-BEH a la Esencia? En la entrega anterior de esta columna en SG 46 expliqué qué son los alfas, el concepto básico de la propuesta de Ivar Jacobson y sus colegas. En particular, el área del Esfuerzo/Proyecto tiene tres alfas: Equipo (Team), Forma de Trabajar (Way of Working) y Trabajo (Work). Al analizar estas alfas nos dimos cuenta de que la vista estática de KUALI-BEH tiene que ver con la definición de la forma de trabajar y la vista operacional con el trabajo mismo. A raíz de esta observación, los colaboradores de Jacobson nos propusieron incorporar KUALI-BEH como extensión de los alfas de Way of Working y Work, lo que quedó documentado como Apéndice B (normativo) del estándar.

En esta ocasión les quiero presentar cómo la vista estática de KUALI-BEH quedó expresada como sub-alfas de Way of Working llamadas Autoría de Práctica (Practice Authoring) y Autoría de Método (Method Authoring).

Autoría de práctica

Es una guía definida de trabajo, con un objetivo específico, que asesora en la manera de producir un resultado a partir de una entrada. La guía proporciona un conjunto sistemático y repetitivo de actividades enfocadas en el logro del objetivo de la práctica y del resultado. Se definen los criterios de terminación, asociados al resultado, para determinar si fue logrado el objetivo. Se requieren competencias particulares para realizar las actividades de la guía, opcionalmente apoyadas por el uso de herramientas. Se pueden asociar las medidas seleccionadas para evaluar el desempeño y el logro de los objetivos de la práctica. Las medidas se estiman y se recogen las mediciones durante la ejecución de la práctica.

La Autoría de Práctica proporciona un marco para que los practicantes definan sus diferentes formas de trabajar. La documentación de la especificación [1], en su anexo B dedicado a KUALI-BEH contiene una plantilla para definir prácticas.

La Figura 2 muestra los estados por los que pasa la autoría de práctica: Identificada, Expresada, Acordada, En Uso, En Optimización y Consolidada.

Figura 2. Los estados de Practice Authoring sub-alfa.

Su uso es recomendado para las organizaciones que no tienen documentadas las formas de trabajar. Sobre todo, se sugiere que las pequeñas organizaciones intenten ponerse de acuerdo y expresar sus formas de trabajar tácitas, empezando por lo que les parezca más importante, para que empiecen a acumular conocimiento explícito compartido por la organización. Cuando tengan definidas varias prácticas interrelacionadas pueden componerlas en un método.

Autoría de método

Un método es una articulación de un conjunto coherente, consistente y completo de las prácticas, con un propósito específico, con el fin de cumplir con las necesidades de los involucrados en condiciones específicas.

La sub-alfa de Autoría de Método pasa por los siguientes estados: Identificado, Integrado, Bien Formado, En Uso, En Optimización y Consolidado, que se ilustran en la figura 3.

Fig 3. Los estados de Method Authoring sub-alfa.

En nuestra propuesta para la autoría de las prácticas y métodos hay dos puntos que considero son novedosos:

Proponemos definición de prácticas y métodos (antes llamados procesos) de manera de “abajo hacia arriba” (bottom – up), a partir de las formas tácitas de trabajar, que cada organización tiene. Es decir, primero las prácticas individuales y luego su composición en métodos. Que luego se pueden ir mejorando en función de los acuerdos y necesidades de la propia organización.
El método bien formado (léase proceso) no es un conjunto de prácticas cualquiera, las prácticas tienen que aportar algo al propósito del método (coherente), ser suficientes para lograrlo (completo) y no generar desperdicios en actividades o productos innecesarios (consistente).

Conclusión

Este es el primer acercamiento a lo que propone KUALI-BEH como parte del nuevo estándar de OMG Esencia. A los interesados les recomiendo revisar el Apéndice B para tener mayor detalle. Con gusto recibo sus comentarios en @hannaoktaba.

Referencias

ESSENCE: Kernel and Language for Software Engineering Methods 1.0. http://www.omg.org/spec/Essence/1.0

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. @hannaoktaba

Tejiendo nuestra red

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Publicado en

Autor

Problemas y Logros

Proceso de desarrollo de software

Calidad de software

Costos

Gestión

Profesión

El Futuro

Tendencias

Retos

Conclusión

Tags

60 Años de la Computación en la UNAM y … en México

Publicado en

Autor

Primera computadora (1958)

Primera institución de investigación (1970)

Primera maestría (1975)

Primera carrera (1977) y las que siguieron

Primera Sociedad (1986) y las que siguieron

Primer acceso académico a Internet (1989)

Primera Red Universitaria de Colaboración en Ingeniería de Software y Bases de Datos (2006)

Primer Centro Virtual de Computación (2017)

Tags

¿Por Qué Siempre Me Falta el Tiempo para el Trabajo?

Publicado en

Autor

Los cinco “ladrones” de mi tiempo

Demasiado trabajo comprometido

Dependencias desconocidas

Trabajo no planificado

Prioridades en conflicto

Trabajo descuidado

Conclusión

¿Por qué mi Equipo Tiene Broncas?

Publicado en

Autor

1. Forming (formación)

2. Storming (enfrentamiento)

Fase 3: Norming (normalización)

Fase 4: Performing (desempeño)

MoProSoft Revive

Publicado en

Autor

Convocatoria para renovar MoProSoft

Tags

Pioneras en la Preocupación por la Calidad en Ingeniería de Software

Publicado en

Autor

Tags

Dime qué Desayunaste y Te Diré qué tan Productivo Estarás Hoy

Publicado en

Autor

¿Y qué tiene que ver la voluntad con todo esto?

Hábitos

Rituales

Modo fluido de trabajo

Propósito 2016: Organicémonos un Poco Más

Publicado en

Autor

Red Universitaria de Colaboración DE Ingeniería de Software y Base de Datos (RedIS&BD)

Red Temática Mexicana de la Ingeniería de Software (REDMIS)

Academia Mexicana de Computación (AMEXCOMP)

Adiós ISO/IEC JTC1 SC7 WG24

Publicado en

Autor

Mi aventura con WG24

Mi despedida de WG24

KUALI- BEH como extensión de las alfas de ESENCIA (ESSENCE)

Publicado en

Autor

Autoría de práctica

Autoría de método

Conclusión