El desarrollo de software es una actividad compleja y reciente, que ha generado su conocimiento en un periodo muy breve, en comparación con otras actividades profesionales: desde la aparición de máquinas que para ser útiles necesitaban ser programadas.
La aparición de componentes que cada dos años doblan la capacidad de sus antecesores [ley de Moore] nos ha rodeado en menos de cuatro décadas de máquinas capaces de procesar miles de millones de operaciones por segundo (MTOPS).
En 1946 ENIAC ocupaba una superficie de 160 m2, pesaba 30 toneladas, y ofrecía una capacidad de proceso de 30.000 instrucciones por segundo. En 2002 El microprocesador Pentium IV a 2 Ghz ocupaba una superficie de 217 mm2 y tenía una capacidad de proceso de 5.300 MTOPS (“Millions of theoretical operations per second)
En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware. De ellos, tres son consecuencia de la ley de Moore:
En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware. De ellos, tres son consecuencia de la ley de Moore:
- Incremento constante de la capacidad de operación.
- Miniaturización.
- Reducción de costes para la producción de hardware.
y a éstos se ha sumado en la última década
- el avance de las comunicaciones entre sistemas.
La consecuencia es obvia: ordenadores potentes, que pueden llevarse en el bolsillo y en permanente conexión con grandes sistemas, redes de comunicación públicas, sistemas de localización GPS, etc.
Estas cuatro líneas de avance han extendido el ámbito de aplicación del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Los ordenadores ya no son máquinas útiles sólo para la banca o el ejército. Se encuentran presentes en todos los ámbitos, por su capacidad de proceso y de comunicación pueden ofrecer soluciones a sistemas cada vez más complejos.
Estas cuatro líneas de avance han extendido el ámbito de aplicación del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Los ordenadores ya no son máquinas útiles sólo para la banca o el ejército. Se encuentran presentes en todos los ámbitos, por su capacidad de proceso y de comunicación pueden ofrecer soluciones a sistemas cada vez más complejos.
Este es el escenario creado por la industria del hardware, y que en las tres últimas décadas ha implicado a los desarrolladores de software en retos a los que no han respondido con solvencia.
Crisis del software. Este problema se identificó por primera vez en 1968 (Bauer, Bolliet, & Helms, 1968), año en el que la organización OTAN celebró la primera conferencia sobre desarrollo de software, y en la que se acuñó el término “crisis del software” para definir a los problemas que surgían en el desarrollo de sistemas de software, cuyos proyectos siempre terminaban tarde, desbordando los presupuestos y con problemas de funcionamiento. También se acuñó el término “ingeniería del software” para describir el conjunto de conocimientos que existían en aquel estado inicial.
Nuestra profesión es muy reciente, se podría decir que aún adolescente (si no una niña) y que no cuenta todavía con una base de conocimiento maduro.
Cuando en los 60 y sobre todo en los 70 y 80 empezaron a hacerse habituales los ordenadores, surgieron los primeros “héroes,” que sin más información que los manuales del operativo y el lenguaje de programación, se remangaban delante del teclado para desarrollar las primeras aplicaciones.
Hasta los 70 los ordenadores fueron máquinas vanguardistas y excesivamente caras. El ejército y la banca eran los únicos sectores que se las permitían, y fueron los militares los primeros escarmentados, de proyectos en los que el software siempre llegaba tarde, mal y nunca; con demasiados errores y desbordando todas agendas previstas.
Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:
- En 1962 se publicó el primer algoritmo para búsquedas binarias (Iverson, 1962).
- C. Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de “GoTo” y la creación de la programación estructurada (Böhm & Jacopini, 1966)
- En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta “GoTo Statement Considered Harmful” en 1968 (Dijkstra, 1968).
- La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens (Stevens, Myers, & Constantine, 1974).
- El primer libro sobre métrica de software fue publicado en 1976 por Tom Gilb (Gilb, 1976).
- El primero sobre análisis de requisitos apareció en 1976 (Bell & Thayer, 1976)
La Tesis: Ingeniería, gestión predictiva y procesos
Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informática de las universidades, y por organismos de estandarización y asesoría para identificar las causas del problema y definir pautas estándar para la producción y mantenimiento del software.
Los esfuerzos desarrollaron en las tres últimas décadas del siglo pasado tres áreas de conocimiento que se revelaron como estratégicas para hacer frente a la crisis del software:
- Ingeniería del software
- Gestión predictiva de proyectos
- Producción basada en procesos.
INGENIERÍA DEL SOFTWARE
Término acuñado en la conferencia de la OTAN de 1968, al definir la necesidad de una disciplina científica que, como ocurre en otras áreas, permita aplicar un enfoque sistemático, disciplinado y cuantificable al desarrollo operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software.
El proyecto más consensuado hasta la fecha para definir las áreas de conocimiento que comprenderían una ingeniería del software es el SWEBOK.
GESTIÓN DE PROYECTOS PREDICTIVA
La necesidad de profesionalizar la gestión de proyectos surgió en los 50, en el ámbito militar, para abordar el desarrollo de complejos sistemas militares que requería coordinar el trabajo conjunto de equipos y disciplinas diferentes, en la construcción de sistemas únicos.
La industria del automóvil siguió los pasos de la militar, aplicando técnicas de gestión de proyectos para la coordinación del trabajo entre áreas y equipos diferentes.
Comenzaron a surgir técnicas específicas, histogramas, cronogramas, los conceptos de ciclo de vida del proyecto o descomposición en tareas (WBS Work Breakdown Structure).
La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.
En los 80 se definieron los objetivos que la gestión de proyectos debía cumplir para poder considerar que el trabajo concluye con éxito:
En los 80 se definieron los objetivos que la gestión de proyectos debía cumplir para poder considerar que el trabajo concluye con éxito:
- Se ejecuta en el tiempo planificado.
- Sin desbordar el presupuesto estimado.
- Satisfaciendo las necesidades del cliente
- Realiza las funcionalidades que necesita.
- Las realiza correctamente y sin errores.
En la actualidad, según el estudio periódico, que desde 1994 realiza Standish Group, escasamente uno de cada tres proyectos de desarrollo de software termina en éxito.
Características de la gestión de proyectos predictiva
- Establece como criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado.
- Asume que el proyecto se desarrolla en un entorno estable y predecible.
- El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos.
- Divide el desarrollo en fases a las que considera “ciclo de vida”, con una secuencia de tipo: concepto, requisitos, diseño, planificación, desarrollo, cierre.
PRODUCCIÓN BASADA EN PROCESOS
Sobre el principio de calidad de Jurán (Juran, 1951), empleado con buenos resultados en los procesos de producción industrial: "La calidad del resultado depende básicamente de la calidad de los procesos empleados en su producción", se desarrollaron también para la industria del software modelos de procesos (ISO 90003, CMMI, ISO 15504...) para que las empresas puedan alcanzar los cuatro beneficios clave de la producción basada en procesos:
- Repetibilidad de resultados. Al conseguir que la calidad del resultado sea consecuencia del proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados.
- Escalabilidad. Es una consecuencia de la repetibilidad. No sólo un equipo consigue resultados homogéneos en todos los proyectos, sino que los obtienen todos los equipos.
- Mejora continua. Al aplicar meta-procesos que trabajan sobre los propios procesos de producción, midiendo y analizando los resultados se obtienen los criterios de gestión necesarios para aplicar medidas que mejoran de forma continua la eficiencia y calidad de los procesos base, y por tanto de los resultados.
- Un know-how propio, consiguiendo finalmente una empresa que sabe hacer, porque su modelo de procesos termina conteniendo un activo valioso de la organización: el conocimiento clave para hacer las cosas bien, con eficiencia y de forma homogénea.
La Antítesis: Agilidad
¿El modelo predictivo es el único posible?
¿Los criterios para determinar el éxito sólo pueden ser el cumplimiento de fechas y costes?
¿Puede haber proyectos que no tengan como finalidad realizar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculados?
¿Y si el cliente no estuviera interesado en saber si el sistema tendrá 20 ó 200 funcionalidades, si estará en beta 6 meses o 2 años?
¿Si su interés fuera poner en el mercado antes que nadie un producto valioso para los clientes, y estar continuamente desarrollando su valor y funcionalidad?
Quizá en algunos proyectos de software el empeño en aplicar prácticas de estimación, planificación, ingeniería de requisitos sea un empeño vano. Quizá la causa de los problemas no sea tanto por una mala aplicación de las prácticas, sino por la aplicación de prácticas inapropiadas.
¿Los criterios para determinar el éxito sólo pueden ser el cumplimiento de fechas y costes?
¿Puede haber proyectos que no tengan como finalidad realizar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculados?
¿Y si el cliente no estuviera interesado en saber si el sistema tendrá 20 ó 200 funcionalidades, si estará en beta 6 meses o 2 años?
¿Si su interés fuera poner en el mercado antes que nadie un producto valioso para los clientes, y estar continuamente desarrollando su valor y funcionalidad?
Quizá en algunos proyectos de software el empeño en aplicar prácticas de estimación, planificación, ingeniería de requisitos sea un empeño vano. Quizá la causa de los problemas no sea tanto por una mala aplicación de las prácticas, sino por la aplicación de prácticas inapropiadas.
Quizá se estén generando “fiascos” al exigir a los clientes criterios de adquisición, y al aplicar a los proyectos procesos de gestión predictivos, cuando se trata de proyectos que no necesitan tanto garantías de previsibilidad en la ejecución, como valor y flexibilidad para trabajar en un entorno cambiante.
En marzo de 2001, 17 críticos de los modelos de mejora basados en procesos, convocados por Kent Beck, que había publicado un par de años antes el libro "Extreme Programming Explained" en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software.
En la reunión se acuñó el término “Métodos Ágiles” para definir a los que estaban surgiendo como alternativa a las metodologías formales: CMM-SW (Paulk, B., Chrissis, & Weber, 1996) precursor del CMMI, PMI, SPICE (proyecto inicial de ISO 15504), etc. a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que son los principios sobre los que se basan estos métodos.
Hasta 2005, entre los defensores de los modelos de procesos y los de modelos ágiles han sido frecuentes las posturas radicales, quizá más ocupadas en descalificar al otro, que en estudiar sus métodos y conocerlos para mejorar los propios.
Hasta 2005, entre los defensores de los modelos de procesos y los de modelos ágiles han sido frecuentes las posturas radicales, quizá más ocupadas en descalificar al otro, que en estudiar sus métodos y conocerlos para mejorar los propios.
Manifiesto Ágil
Valoramos más a los individuos y su interacción que a los procesos y las herramientas.
Valoramos más a los individuos y su interacción que a los procesos y las herramientas.
Este es posiblemente el principio más importante del manifiesto.
Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento tácito, sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la reingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.
Valoramos más el software que funciona que la documentación exhaustiva.
Poder ver anticipadamente cómo se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.
Valoramos más la colaboración con el cliente que la negociación contractual.
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle al principio del proyecto, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio del cliente.
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle al principio del proyecto, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio del cliente.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto.
Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias de responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo
de trabajo. Los modelos de contrato por obra no encajan.
Valoramos más la respuesta al cambio que el seguimiento de un plan.
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Conocimiento en evolución continua
Cuestionar lo conocido es el motor de la evolución del conocimiento.
No es nuevo. Ya lo formuló Platón, es la base de la teoría dialéctica , y como recuerdan Nonaka y Takeuchi, (Nonaka Takeuchi, 2004) este patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que cuestionan las tesis anteriores, y producen nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.
La evolución del conocimiento sigue el patrón dialéctico de tesis – antítesis y síntesis.
Los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software.
La agilidad es su antítesis, y estamos generando en estos años la síntesis: el resultado que se enriquece de ambos, y logra un conocimiento más completo y depurado
Los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software.
La agilidad es su antítesis, y estamos generando en estos años la síntesis: el resultado que se enriquece de ambos, y logra un conocimiento más completo y depurado
En los 80 y 90 comienza a cristalizar la primera base de conocimiento: la tesis.
- Los modelos de procesos específicos: ISO9000-3 CMM’s, SPICE-ISO 15504, Bootstrap, etc.
- Aplicación del mismo patrón predictivo de gestión de proyectos, aplicado en otras ingenierías:PMI, IPMA.
- Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK (Software Engineering Coordinating Comittee, 2000)
En los 90, llega la difusión y aplicación de este conocimiento. En algunos ámbitos da buenos resultados, y en otros genera la réplica "dialéctica": El Manifiesto Ágil, que cuestiona la validez de los modelos basados en procesos y la gestión predictiva para el desarrollo de software.
Se radicalizan las posturas entre ambas líneas y se genera (y se está generando) la tensión entre contrarios que mueve la evolución dialéctica del conocimiento.
Se radicalizan las posturas entre ambas líneas y se genera (y se está generando) la tensión entre contrarios que mueve la evolución dialéctica del conocimiento.
Algunos ejemplos de esta tensión:
"La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede
negociar"…
"La evaluación en CMM depende más de una buena presentación en papel que da la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el desarrollo y puesta en producción de un sistema en el panorama tecnológico".(Orr., 2003)
"Si uno pregunta a un ingeniero de software típico si cree que CMM se puede aplicar a los métodos
ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica".(Turner; Jain, 2002)
En los últimos años se apuntan ya las tendencias de la evolución hacia la síntesis:
En estos momentos autoridades de la Ingeniería del Software como Barry Boehm y Richard Turner hablan de balancear la agilidad y la disciplina (Boehm; Turner, 2003) ISO comprueba y anuncia que los modelos desarrollados funcionan en unos entornos, pero no en otros, y ha creado ya comités para desarrollar versiones más ligeras (Laporte; April, 2005).
Surgen iniciativas de normalización como MoProSoft que buscan puntos intermedios entre ambos extremos.
Muchos profesionales plantean dudas sobre ambos extremos, y prueban mezclas y soluciones híbridas.
Ahora estamos a mitad de resolución entre esa tesis y su antítesis ágil.
La contradicción produce desconcierto, pero además en nuestro caso, la velocidad de comunicación facilitada por Internet, y el apresuramiento general del entorno, hace que se solapen las tres tendencias del ciclo.
ISO 15504, CMMI, Scrum, DSDM, Extreme Programming, etc. son grandes aportaciones y es mucho lo que se puede aprender de ellos, pero es iluso pensar de cualquiera de ellas que es La Solución. El conocimiento siempre estará evolucionando, y no tardarán mucho en quedar mejorados. Los libros sobre CMMI o Scrum de hoy, cuando los leamos dentro de pocos años serán textos de conocimiento desfasado.
No hay comentarios:
Publicar un comentario