Published 17 years ago
(updated 13 years ago)
Cuidado con las Semejanzas
Desde hace mas de 40 años, cuando se adopta a la ingeniería de software como modelo para crear programas de cómputo, los ingenieros de software nos hemos dado a la tarea de asignar diferentes analogías acerca de cómo entender el desarrollo de software, basta con hacer una búsqueda con el texto “Desarrollar software es como” para darnos cuenta de la utilidad y creatividad que encontramos para explicar nuestra realidad, pues al final, un sistema de cómputo es una abstracción, una simulación en bits de lo que nos acontece.
Una analogía se realiza asumiendo que si dos entes son semejantes en uno o varios aspectos, entonces es probable que se parezcan en otras facetas, este escrito pretende ser un panfleto técnico donde se analizan algunas analogías planteadas y cuyo único objetivo es el sembrar la semilla de la reflexión en todos aquellos colegas que se apasionan por eso que llamamos: Ingeniería de software…
De la poesía
Esta analogía, parte del hecho que el software, al tener un lenguaje, se lee y se escribe, Richard Gabriel dijo: “Desarrollar software es como escribir poesía, antes de hacer un buen poema tienes que leer miles de fuentes para aprender a escribir con la métrica adecuada y adoptar un estilo propio”. Esta analogía parece muy buena, pues si analizamos el proceso de escribir poesía, normalmente se comienza por redactar un párrafo, para luego evaluarlo y darnos cuenta que no es lo que buscamos y destruimos el papel donde está escrito.
Después escribimos un nuevo párrafo, y nuevamente lo desechamos porque no cumple con las características necesarias y a generar un nuevo párrafo, este último parece no estar tan mal, se adapta, se mejora y al terminar el proceso tenemos un excelente párrafo, claro, con la inversión/desperdicio de una considerable cantidad de tiempo al haber tirado tres borradores antes de llegar al definitivo.
Esta analogía al igual que todas aquellas donde se compara la ingeniería de software con un proceso de arte creativo (producción cinematográfica, escultura, pintura) por experimentación, ha sido de gran utilidad pues al evaluar nuestro proceso desde este enfoque nos damos cuenta que esta aproximación, jamás será la opción mas óptima cuando ya sabemos qué es lo que queremos desarrollar y conocemos las restricciones, pero sí funcionará para la creación e investigación de nuevas e innovadoras piezas de software.
De la línea de producción
Esta analogía nos permite comprender como el proceso de desarrollo de software, desde una perspectiva de fabricación en serie, donde con base en una especificación inicial, el producto se construye, se valida, se empaca y se entrega, en esta categoría caen todas aquellas analogías que hacen referencia a una cadena de valor: manufactura, restaurantes de comida rápida, ensambladoras, etc. Principalmente se enfocan en como detectar lo que realmente le está agregando valor a mi producto terminado.
Esta es una analogía muy común, y que llega a su formalización con la liberación del “Framework for Software Product Line Practice”, un marco de trabajo creado por el SEI (Software Engineering Institue) donde claramente se define una línea de producción de software como:
“(…) Subconjunto de sistemas de software que comparten funcionalidades comunes satisfaciendo las necesidades específicas de un segmento en particular, y que son previamente desarrolladas con base en un conjunto de activos de forma preescrita”
Ese proceso de fabricación implica el uso de entornos de desarrollo especializados y configurados como esquemas, Domain Specific Languages (DSLs), patrones, frameworks, generadores de código, librerías especializadas, etc, todos coordinados y definidos de tal forma que integrados formen un tipo determinado de aplicaciones.
“Los conceptos de fábrica se aplican de forma correcta a compañías donde se necesitan desarrollar varias versiones de sistemas similares o la construcción de soluciones basadas en un conjunto de requerimientos bien entendidos y con muchas restricciones externas”
(CUSUMANO Michael, “The business of Software”, Nueva York, 2004).
Como lo escribe Cusumano, esta aproximación funciona para desarrollos repetitivos y para un dominio o industria en especifico, pero como podemos notar, el proceso creativo queda completamente mermado por el proceso de construcción, y los problemas comienzan cuando queremos incluir como parte del proceso de fabricación un desarrollo de investigación para crear nuevas piezas de software, donde no existe un conjunto de activos que nos permiten fabricar los componentes de nuestra aplicación.
De la ingeniería civil
Esta analogía ha sido utilizada por muchos años y se fundamenta en las similitudes que existen entre el proceso de construcción inmobiliaria y el proceso de desarrollo de software.
Es un hecho que no es lo mismo edificar una casa pequeña, que construir un rascacielos, pero para ambos se necesita analizar las necesidades, diseñar un conjunto de planos, comenzar la construcción, validar que esté quedando como fue acordado y finalmente entregarla.
Como en cualquier proyecto de ingeniería, necesitas un plan para gestionar el proyecto, considerar componentes existentes que se pueden integrar, un conjunto de principios y herramientas estandarizadas para la construcción. Puedes gestionar el proyecto de inicio a fin, o dividirlo en pequeñas mejoras (Iterativas) con revisiones periódicas con los involucrados.
La polémica comienza cuando incorporamos la siguiente cuestión: Los edificios son bienes físicos, mientras que el software, es un bien intelectual”, y desde esta perspectiva, el software nos permite realizar transformaciones imposibles en el mundo físico. Esto cambia por completo el panorama, pues los principios y reglas de los que hablamos anteriormente, en el mundo del software permanecen en constante evolución, y es entonces cuando nuestros proceso de diseño, con base a un conjunto de necesidades tiene que tomar en cuenta que el entorno se modificará y los involucrados cambiarán de parecer, y será entonces necesario crear una nueva pieza de software, donde este proceso es un proceso creativo, mas parecido al de escribir poesía.
De la ingeniería de software
La ingeniería de software es un campo muy joven aun, tanto que resulta imposible evitar su evolución, y como consecuencia las analogías con las que la describimos tienden a cambiar por completo, de ser complementarias a ser conflictivas, algunas mejores que otras, todas tratando de explicar nuestra experiencia, lo que no es válido es tratar de forzar nuestros procesos para adaptarlos a la analogía, pues al final, la ingeniería de software es un modelo procesal para desarrollar sistemas de cómputo que cumplan con las necesidades de los involucrados, y jamás será: “hacer hamburguesas de
McDonalds”, “edificar construcciones”, “escribir novelas”, “fabricar panecillos”, “hacer una película” o “cocinar chilaquiles”.
“Comparar con otras actividades, es útil cuando te permite formular preguntas, pero es peligroso cuando lo utilizas para justificar tus respuestas (…), esto nos puede ayudar a revisar nuestras prácticas desde un punto de vista diferente, a cuestionarnos sobre como trabajamos”. Martin Fowler, December 2004.
Conclusión
Podemos utilizar las analogías para facilitar la comprensión y explicar partes del proceso, pero jamás para explicar todo el ciclo, porque ese ciclo es único y flexible, pues desde mi punto de vista eso hace que la nuestra, sea un rama única e incomparable.
Desde hace mas de 40 años, cuando se adopta a la ingeniería de software como modelo para crear programas de cómputo, los ingenieros de software nos hemos dado a la tarea de asignar diferentes analogías acerca de cómo entender el desarrollo de software, basta con hacer una búsqueda con el texto “Desarrollar software es como” para darnos cuenta de la utilidad y creatividad que encontramos para explicar nuestra realidad, pues al final, un sistema de cómputo es una abstracción, una simulación en bits de lo que nos acontece.
Una analogía se realiza asumiendo que si dos entes son semejantes en uno o varios aspectos, entonces es probable que se parezcan en otras facetas, este escrito pretende ser un panfleto técnico donde se analizan algunas analogías planteadas y cuyo único objetivo es el sembrar la semilla de la reflexión en todos aquellos colegas que se apasionan por eso que llamamos: Ingeniería de software…
De la poesía
Esta analogía, parte del hecho que el software, al tener un lenguaje, se lee y se escribe, Richard Gabriel dijo: “Desarrollar software es como escribir poesía, antes de hacer un buen poema tienes que leer miles de fuentes para aprender a escribir con la métrica adecuada y adoptar un estilo propio”. Esta analogía parece muy buena, pues si analizamos el proceso de escribir poesía, normalmente se comienza por redactar un párrafo, para luego evaluarlo y darnos cuenta que no es lo que buscamos y destruimos el papel donde está escrito.
Después escribimos un nuevo párrafo, y nuevamente lo desechamos porque no cumple con las características necesarias y a generar un nuevo párrafo, este último parece no estar tan mal, se adapta, se mejora y al terminar el proceso tenemos un excelente párrafo, claro, con la inversión/desperdicio de una considerable cantidad de tiempo al haber tirado tres borradores antes de llegar al definitivo.
Esta analogía al igual que todas aquellas donde se compara la ingeniería de software con un proceso de arte creativo (producción cinematográfica, escultura, pintura) por experimentación, ha sido de gran utilidad pues al evaluar nuestro proceso desde este enfoque nos damos cuenta que esta aproximación, jamás será la opción mas óptima cuando ya sabemos qué es lo que queremos desarrollar y conocemos las restricciones, pero sí funcionará para la creación e investigación de nuevas e innovadoras piezas de software.
De la línea de producción
Esta analogía nos permite comprender como el proceso de desarrollo de software, desde una perspectiva de fabricación en serie, donde con base en una especificación inicial, el producto se construye, se valida, se empaca y se entrega, en esta categoría caen todas aquellas analogías que hacen referencia a una cadena de valor: manufactura, restaurantes de comida rápida, ensambladoras, etc. Principalmente se enfocan en como detectar lo que realmente le está agregando valor a mi producto terminado.
Esta es una analogía muy común, y que llega a su formalización con la liberación del “Framework for Software Product Line Practice”, un marco de trabajo creado por el SEI (Software Engineering Institue) donde claramente se define una línea de producción de software como:
“(…) Subconjunto de sistemas de software que comparten funcionalidades comunes satisfaciendo las necesidades específicas de un segmento en particular, y que son previamente desarrolladas con base en un conjunto de activos de forma preescrita”
Ese proceso de fabricación implica el uso de entornos de desarrollo especializados y configurados como esquemas, Domain Specific Languages (DSLs), patrones, frameworks, generadores de código, librerías especializadas, etc, todos coordinados y definidos de tal forma que integrados formen un tipo determinado de aplicaciones.
“Los conceptos de fábrica se aplican de forma correcta a compañías donde se necesitan desarrollar varias versiones de sistemas similares o la construcción de soluciones basadas en un conjunto de requerimientos bien entendidos y con muchas restricciones externas”
(CUSUMANO Michael, “The business of Software”, Nueva York, 2004).
Como lo escribe Cusumano, esta aproximación funciona para desarrollos repetitivos y para un dominio o industria en especifico, pero como podemos notar, el proceso creativo queda completamente mermado por el proceso de construcción, y los problemas comienzan cuando queremos incluir como parte del proceso de fabricación un desarrollo de investigación para crear nuevas piezas de software, donde no existe un conjunto de activos que nos permiten fabricar los componentes de nuestra aplicación.
De la ingeniería civil
Esta analogía ha sido utilizada por muchos años y se fundamenta en las similitudes que existen entre el proceso de construcción inmobiliaria y el proceso de desarrollo de software.
Es un hecho que no es lo mismo edificar una casa pequeña, que construir un rascacielos, pero para ambos se necesita analizar las necesidades, diseñar un conjunto de planos, comenzar la construcción, validar que esté quedando como fue acordado y finalmente entregarla.
Como en cualquier proyecto de ingeniería, necesitas un plan para gestionar el proyecto, considerar componentes existentes que se pueden integrar, un conjunto de principios y herramientas estandarizadas para la construcción. Puedes gestionar el proyecto de inicio a fin, o dividirlo en pequeñas mejoras (Iterativas) con revisiones periódicas con los involucrados.
La polémica comienza cuando incorporamos la siguiente cuestión: Los edificios son bienes físicos, mientras que el software, es un bien intelectual”, y desde esta perspectiva, el software nos permite realizar transformaciones imposibles en el mundo físico. Esto cambia por completo el panorama, pues los principios y reglas de los que hablamos anteriormente, en el mundo del software permanecen en constante evolución, y es entonces cuando nuestros proceso de diseño, con base a un conjunto de necesidades tiene que tomar en cuenta que el entorno se modificará y los involucrados cambiarán de parecer, y será entonces necesario crear una nueva pieza de software, donde este proceso es un proceso creativo, mas parecido al de escribir poesía.
De la ingeniería de software
La ingeniería de software es un campo muy joven aun, tanto que resulta imposible evitar su evolución, y como consecuencia las analogías con las que la describimos tienden a cambiar por completo, de ser complementarias a ser conflictivas, algunas mejores que otras, todas tratando de explicar nuestra experiencia, lo que no es válido es tratar de forzar nuestros procesos para adaptarlos a la analogía, pues al final, la ingeniería de software es un modelo procesal para desarrollar sistemas de cómputo que cumplan con las necesidades de los involucrados, y jamás será: “hacer hamburguesas de
McDonalds”, “edificar construcciones”, “escribir novelas”, “fabricar panecillos”, “hacer una película” o “cocinar chilaquiles”.
“Comparar con otras actividades, es útil cuando te permite formular preguntas, pero es peligroso cuando lo utilizas para justificar tus respuestas (…), esto nos puede ayudar a revisar nuestras prácticas desde un punto de vista diferente, a cuestionarnos sobre como trabajamos”. Martin Fowler, December 2004.
Conclusión
Podemos utilizar las analogías para facilitar la comprensión y explicar partes del proceso, pero jamás para explicar todo el ciclo, porque ese ciclo es único y flexible, pues desde mi punto de vista eso hace que la nuestra, sea un rama única e incomparable.
- Log in to post comments