Resumen: con la información que tengo disponible, argumento por que creo que el problema de Integra2 es un problema de mal uso (o uso nulo) de los principios de "ingeniería de sistemas". No se ha presentado dicho enfoque debido al desconocimiento de dicha disciplina (la ingeniería de sistemas) en Costa Rica. Para ello uso como base la investigación realizada por Canal 9 sobre la implementación de dicho sistema, citada en este post.
Es hasta hoy que logré ver un interesantísimo reportaje de Canal 9 donde hacen una investigación más a fondo sobre los detalles de los problemas de la implementación del sistema Integra2, el ya impopular sistema implementado para hacer los pagos del MEP, cuyos fallos hay provocado la huelga que trasciende dos gobiernos.
La primera parte de ese reportaje puede ser vista acá
Y la segunda parte puede ser vista acá
Lamentablemente, a pesar de que en el reportaje se hace una investigación tan exhaustiva, siento que al final los reporteros no hacen las preguntas correctas a los implementadores, sobre todo, cuando interrogan a los responsables del Grupo Asesor de Informática sobre por qué si ellos dicen que este funciona bien, los pagos no se están dando correctamente.
¿Es acaso posible que el software esté (teóricamente) perfectamente diseñado y a pesar de esto se den estos fallos? Mi tesis es que sí. Llego a esa conclusión utilizando la perspectiva de ingeniería de sistemas para explicar la razón de la aparente paradoja.
La "ingeniería de sistemas" no es sinónimo de "ingeniería informática" o "ingeniería en computación" como muchas veces se entiende en Costa Rica. La ingeniería en sistemas es un "enfoque metódico y disciplinado para el diseño, realización, manejo técnico, operación y retiro de un sistema" según el manual de Ingeniería de Sistemas de la NASA (ver aquí) (traducción libre). La explicación en inglés de Wikipedia también está bastante completa (ver aquí). La versión en español lamentablemente es muy ambigua.
Es decir, la ingeniería en sistemas es un enfoque para manejar proyectos multidisciplinarios complejos. Y cuando se habla de un enfoque multidisciplinario, hablamos de que el ingeniero de sistemas ve como partes del sistema no únicamente lo considerado "técnico" o de "ingeniería", sino que en sus consideraciones debe tomar en cuenta el factor humano y las interfaces con la burocracia, por mencionar algunas.
En adelante, para este análisis, cuando me refiero a "equipo implementador", hablo de el equipo que implementó todo el sistema, tomando en cuenta a la gente del MEP y del Grupo Asesor de Informática, entre otros. Cuando me refiera al "equipo de ingeniería de sistemas" me refiero al equipo que existe, o debería existir (desconozco el caso) dentro del MEP, encargado de hacer la ingeniería de sistemas del proyecto, es decir, asegurarse la correcta implementación de un sistema complejo y multidisciplinario.
La importancia de la "Ingeniería de Interfaces"
La ingeniería en sistemas es en parte una "ingeniería de interfaces". Cuando un sistema es complejo, muchos bloques de dicho sistema son hechos por diferentes organizaciones. Es así la responsabilidad del equipo de ingeniería de sistemas el determinar como la interfaz entre un sistema u otro debe ser hecha. Hago un ejemplo sencillo: si una persona diseña un radio, y otra diseña el sistema para transmitir corriente al radio, el ingeniero de sistemas sería el que determinaría (y obligaría en nuestro ejemplo teórico) a ambos equipos de diseño a usar el mismo tipo de conector para que los sistemas se puedan interconectar. O que alguien diseñe un equipo que se conecta por puerto serial a otro sistema y ese sistema solo tiene conector USB (ver imagen) ¿Podremos conectar los dos sistemas? Si los sistemas necesitan estar conectados para funcionar, evidentemente no van a funcionar.
Sin embargo ¿Pueden estar dos sistemas perfectamente bien diseñados, y sin embargo no funcionar? ¿Verdad que la respuesta es sí, si no nos ocupamos de la interfaz?
Imagínense que tan solo estoy hablando de un ejemplo simple. Imaginémonos la dimensión de los problemas de interfaz con sistemas compejos. La conclusión es que no se puede subdimensionar la importancia de preocuparse por la "ingeniería de interfaces" que es parte de la ingeniería de sistemas.
Quiero insistir en un punto: la ingeniería de interfaces de ingeniería de sistemas, no comprende únicamente interfaces físicas: en un proyecto como Integra2, existen interfaces con la burocracia (MEP) y de tipo legal (Contraloría) por ejemplo. El conocimiento de los requerimientos de los participantes en la implementación del proyecto por parte del equipo de ingeniería de sistemas es fundamental. Por eso, no es justificable que un atraso se de por que "no se sabía de ciertas normas" como se dice en el video 1.
La importancia de la "Ingeniería de Requerimientos"
La buena ejecución de los requerimientos es también responsabilidad de un equipo de ingeniería de sistemas que funciona adecuadamente. Los requerimientos son independientes de la solución, y deben ser escritos de esa manera. Así, en dichos requerimientos deben ser consideradas las etapas de implementación del sistema (que parece no fue considerada) para que la contingencia en caso de problemas que se requiere de un sistema sensible sea considerada.
La primera parte del reportaje deja claro que hubo muchísima ambigüedad a la hora de determinar los requerimientos por los cuales se eligió a una compañía. Incluso argumenta el reportero (no tengo elementos para decir que esto es así) que la empresa a la que le fue adjudicada fue medida con parámetros diferentes.
Está claro, además, que dentro de los requerimientos no se tomó en consideración la contingencia para la implementación del sistema. Es decir, no se puso como requerimiento que la transición no afectara a los maestros, utilizando un parámetro medible para determinar si esa afectación no se dio. Si dicho requerimiento existiera para la implementación de Integra2, solo podrían haber dos escenarios: que el equipo implementador falló o que no se cumplió el requerimiento.
La importancia de la "ingeniería de riesgos"
Mi jefe siempre dice lo siguiente: ningún sistema va a funcionar de la manera en la que usted creyó que iba a funcionar. Además, le agregaría, siempre habrá un problema que afectará al sistema que usted nunca pensó. La ingeniería, y en parte el arte, de determinar de manera anticipada como actuar si algo sale mal es parte fundamental de la ingeniería de sistemas. Yo lo voy a llamar acá "ingeniería de riesgos".
Evidentemente, en la implementación de Integra2, no se hizo una buena ingeniería de riesgos. Una buena ingeniería de riesgos hubiera planteado una salida alternativa en caso de que el sistema no funcionara adecuadamente, debido al impacto que tiene un fallo en dicho sistema: si falla, hay gente que se queda sin comer. Si eso no es sensible, entonces yo no se que sí lo es.
La responsabilidad de esa ingeniería de riesgos es, de nuevo, del equipo de ingeniería de sistemas.
La importancia de la administración de los cronogramas
Es igualmente responsabilidad del equipo de ingeniería en sistemas la administración del cronograma. En caso de que no se cumpla alguna fecha límite, la justificación tiene que venir de los aspectos considerados en la ingeniería de riesgos, o como una justificación de un aspecto no considerado. No está de sobra decir que se tiene que justificar igualmente por que dicho aspecto no fue considerado en los requerimientos y/o en los riesgos.
Mi teoría de por que falló el sistema: mala o nula ingeniería de sistemas.
Los elementos de juicio con los que cuento ahora, unidos a la explicación que acabo de hacer, me llevan a la conclusión de que se hizo una mala o nula ingeniería de sistemas por que:
1) No se hizo una buena ingeniería de interfaces: los problemas con los digitadores del sistema o con la Contraloría, para mencionar alguno, son muestra de esto.
2) No se hizo una buena ingeniería de requerimientos: los requerimientos debieron haber contemplado el proceso de cambio entre un sistema y otro.
3) No se hizo una buena ingeniería de riesgos: las consecuencias (no pagos, una huelga alargada) son pruebas irrefutables de esto.
4) No se hizo una buena administración de cronogramas: el incumplimiento de plazos lleva a esta conclusión.
Todos estos puntos son responsabilidad del ingeniero o equipo de ingeniería de sistemas, y se pudieron dar aún si teóricamente el software funciona de acuerdo a los requerimientos.
Mi argumento es, de esta manera, que un adecuado uso de la ingeniería en sistemas hubiera evitado, sino totalmente, al menos la mayoría de los problemas presentes en este momento en la implementación del sistema "Integra2"
Por favor interpretar esto como conclusiones hechas con información limitada. ´Quiero aportar desde la perspectiva de ingeniería en sistemas una visión de los problemas que están sucediendo, de tal manera que este problema sea un "caso de estudio" y aprendamos de él a futuro.
Es hasta hoy que logré ver un interesantísimo reportaje de Canal 9 donde hacen una investigación más a fondo sobre los detalles de los problemas de la implementación del sistema Integra2, el ya impopular sistema implementado para hacer los pagos del MEP, cuyos fallos hay provocado la huelga que trasciende dos gobiernos.
La primera parte de ese reportaje puede ser vista acá
Y la segunda parte puede ser vista acá
Lamentablemente, a pesar de que en el reportaje se hace una investigación tan exhaustiva, siento que al final los reporteros no hacen las preguntas correctas a los implementadores, sobre todo, cuando interrogan a los responsables del Grupo Asesor de Informática sobre por qué si ellos dicen que este funciona bien, los pagos no se están dando correctamente.
¿Es acaso posible que el software esté (teóricamente) perfectamente diseñado y a pesar de esto se den estos fallos? Mi tesis es que sí. Llego a esa conclusión utilizando la perspectiva de ingeniería de sistemas para explicar la razón de la aparente paradoja.
La "ingeniería de sistemas" no es sinónimo de "ingeniería informática" o "ingeniería en computación" como muchas veces se entiende en Costa Rica. La ingeniería en sistemas es un "enfoque metódico y disciplinado para el diseño, realización, manejo técnico, operación y retiro de un sistema" según el manual de Ingeniería de Sistemas de la NASA (ver aquí) (traducción libre). La explicación en inglés de Wikipedia también está bastante completa (ver aquí). La versión en español lamentablemente es muy ambigua.
Es decir, la ingeniería en sistemas es un enfoque para manejar proyectos multidisciplinarios complejos. Y cuando se habla de un enfoque multidisciplinario, hablamos de que el ingeniero de sistemas ve como partes del sistema no únicamente lo considerado "técnico" o de "ingeniería", sino que en sus consideraciones debe tomar en cuenta el factor humano y las interfaces con la burocracia, por mencionar algunas.
En adelante, para este análisis, cuando me refiero a "equipo implementador", hablo de el equipo que implementó todo el sistema, tomando en cuenta a la gente del MEP y del Grupo Asesor de Informática, entre otros. Cuando me refiera al "equipo de ingeniería de sistemas" me refiero al equipo que existe, o debería existir (desconozco el caso) dentro del MEP, encargado de hacer la ingeniería de sistemas del proyecto, es decir, asegurarse la correcta implementación de un sistema complejo y multidisciplinario.
La importancia de la "Ingeniería de Interfaces"
La ingeniería en sistemas es en parte una "ingeniería de interfaces". Cuando un sistema es complejo, muchos bloques de dicho sistema son hechos por diferentes organizaciones. Es así la responsabilidad del equipo de ingeniería de sistemas el determinar como la interfaz entre un sistema u otro debe ser hecha. Hago un ejemplo sencillo: si una persona diseña un radio, y otra diseña el sistema para transmitir corriente al radio, el ingeniero de sistemas sería el que determinaría (y obligaría en nuestro ejemplo teórico) a ambos equipos de diseño a usar el mismo tipo de conector para que los sistemas se puedan interconectar. O que alguien diseñe un equipo que se conecta por puerto serial a otro sistema y ese sistema solo tiene conector USB (ver imagen) ¿Podremos conectar los dos sistemas? Si los sistemas necesitan estar conectados para funcionar, evidentemente no van a funcionar.
Imagínense que tan solo estoy hablando de un ejemplo simple. Imaginémonos la dimensión de los problemas de interfaz con sistemas compejos. La conclusión es que no se puede subdimensionar la importancia de preocuparse por la "ingeniería de interfaces" que es parte de la ingeniería de sistemas.
Quiero insistir en un punto: la ingeniería de interfaces de ingeniería de sistemas, no comprende únicamente interfaces físicas: en un proyecto como Integra2, existen interfaces con la burocracia (MEP) y de tipo legal (Contraloría) por ejemplo. El conocimiento de los requerimientos de los participantes en la implementación del proyecto por parte del equipo de ingeniería de sistemas es fundamental. Por eso, no es justificable que un atraso se de por que "no se sabía de ciertas normas" como se dice en el video 1.
La importancia de la "Ingeniería de Requerimientos"
La buena ejecución de los requerimientos es también responsabilidad de un equipo de ingeniería de sistemas que funciona adecuadamente. Los requerimientos son independientes de la solución, y deben ser escritos de esa manera. Así, en dichos requerimientos deben ser consideradas las etapas de implementación del sistema (que parece no fue considerada) para que la contingencia en caso de problemas que se requiere de un sistema sensible sea considerada.
La primera parte del reportaje deja claro que hubo muchísima ambigüedad a la hora de determinar los requerimientos por los cuales se eligió a una compañía. Incluso argumenta el reportero (no tengo elementos para decir que esto es así) que la empresa a la que le fue adjudicada fue medida con parámetros diferentes.
Está claro, además, que dentro de los requerimientos no se tomó en consideración la contingencia para la implementación del sistema. Es decir, no se puso como requerimiento que la transición no afectara a los maestros, utilizando un parámetro medible para determinar si esa afectación no se dio. Si dicho requerimiento existiera para la implementación de Integra2, solo podrían haber dos escenarios: que el equipo implementador falló o que no se cumplió el requerimiento.
La importancia de la "ingeniería de riesgos"
Mi jefe siempre dice lo siguiente: ningún sistema va a funcionar de la manera en la que usted creyó que iba a funcionar. Además, le agregaría, siempre habrá un problema que afectará al sistema que usted nunca pensó. La ingeniería, y en parte el arte, de determinar de manera anticipada como actuar si algo sale mal es parte fundamental de la ingeniería de sistemas. Yo lo voy a llamar acá "ingeniería de riesgos".
Evidentemente, en la implementación de Integra2, no se hizo una buena ingeniería de riesgos. Una buena ingeniería de riesgos hubiera planteado una salida alternativa en caso de que el sistema no funcionara adecuadamente, debido al impacto que tiene un fallo en dicho sistema: si falla, hay gente que se queda sin comer. Si eso no es sensible, entonces yo no se que sí lo es.
La responsabilidad de esa ingeniería de riesgos es, de nuevo, del equipo de ingeniería de sistemas.
La importancia de la administración de los cronogramas
Es igualmente responsabilidad del equipo de ingeniería en sistemas la administración del cronograma. En caso de que no se cumpla alguna fecha límite, la justificación tiene que venir de los aspectos considerados en la ingeniería de riesgos, o como una justificación de un aspecto no considerado. No está de sobra decir que se tiene que justificar igualmente por que dicho aspecto no fue considerado en los requerimientos y/o en los riesgos.
Mi teoría de por que falló el sistema: mala o nula ingeniería de sistemas.
Los elementos de juicio con los que cuento ahora, unidos a la explicación que acabo de hacer, me llevan a la conclusión de que se hizo una mala o nula ingeniería de sistemas por que:
1) No se hizo una buena ingeniería de interfaces: los problemas con los digitadores del sistema o con la Contraloría, para mencionar alguno, son muestra de esto.
2) No se hizo una buena ingeniería de requerimientos: los requerimientos debieron haber contemplado el proceso de cambio entre un sistema y otro.
3) No se hizo una buena ingeniería de riesgos: las consecuencias (no pagos, una huelga alargada) son pruebas irrefutables de esto.
4) No se hizo una buena administración de cronogramas: el incumplimiento de plazos lleva a esta conclusión.
Todos estos puntos son responsabilidad del ingeniero o equipo de ingeniería de sistemas, y se pudieron dar aún si teóricamente el software funciona de acuerdo a los requerimientos.
Mi argumento es, de esta manera, que un adecuado uso de la ingeniería en sistemas hubiera evitado, sino totalmente, al menos la mayoría de los problemas presentes en este momento en la implementación del sistema "Integra2"
Por favor interpretar esto como conclusiones hechas con información limitada. ´Quiero aportar desde la perspectiva de ingeniería en sistemas una visión de los problemas que están sucediendo, de tal manera que este problema sea un "caso de estudio" y aprendamos de él a futuro.
2 comentarios:
Pareciera que te referís a los fundamentos de administración de proyectos
Óscar: aunque la administración de proyectos en efecto coincide con la ingeniería de sistemas, tienen sus diferencias. Revise por ejemplo la página 4 del "NASA Systems Engineering Handbook" que cito en este documento http://foiaelibrary.gsfc.nasa.gov/_assets/doclibBidder/tech_docs/5.%20NASA%20SP-6105%20Rev%201%20(Sys%20Eng%20Handbook).pdf
Publicar un comentario