archivo

Archivo de la etiqueta: Robert C. Martin

Los procesos y herramientas son instrumentos que utilizados de manera adecuada pueden ayudarnos a conseguir los objetivos. El problema lo tenemos cuando se cree que los objetivos se consiguen, sobre todo, por su aplicación, lo que provoca que pasen a la categoría de fines en lugar de la de instrumentos: “si cumplo con los procesos y hago un buen uso de las herramientas que lo acompañan el proyecto saldrá bien”.

Si centras tu atención en el proceso pierdes tu enfoque en el producto y se tiende a ignorar el contexto. Todo ello por la idea de que la solución la proporciona el proceso y que eso está por encima de cualquier contingencia que se pueda producir.

Robert C. Martin realiza la siguiente reflexión: “El exceso de confianza en las herramientas y procedimientos y la falta de confianza en la inteligencia y en la experiencia son recetas para el desastre”.

A veces es la propia organización la que empuja a los desarrolladores a centrarse en el proceso, independientemente de la importancia que ellos piensen que pueda tener en el desarrollo de software. Cuando esto ocurre habrá personas que por comodidad y también por pragmatismo (hacia ellos y no hacia el proyecto y el producto) caigan en la cultura del cumplimiento: “yo he seguido los procesos de manera escrupulosa, ahí tienes todos los entregables, si el proyecto no ha salido bien no soy el responsable”.

Si el desarrollo de software fuera solo cuestión de procesos (ágiles o no) la mayoría de los proyectos no tendrían problemas y serían rentables tanto para clientes como para proveedores, ¿es esa la realidad?, se necesita algo más y eso lo ponen las personas que trabajan en ellos.

Una vez analizados los principios y valores del manifiesto ágil, en este artículo se va a realizar un breve perfil de sus diecisiete participantes, con el objetivo de que se pueda apreciar que todo el equipo de personas que participaron eran profesionales de reconocido prestigio y que en su trayectoria profesional tenían experiencia e incluso habían publicado artículos y libros sobre la aplicación de estrategias que posteriormente a alto nivel se plasmaron en el manifiesto ágil.

– Kent Beck: Americano. Creador de la metodología de programación extrema y de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development). Coautor de JUnit. Promotor de la reunión que dio lugar a la creación de manifiesto ágil para el desarrollo de software.

– Mike Beedle: Americano. Ha sido uno de los pioneros en la aplicación de Scrum (desde 1995) en proyectos de desarrollo de software en diferentes organizaciones y tipos de sistemas (en cuanto al proceso o procesos de negocio que tratan de informatizar).

– Arie van Bennekum: Holandés. Jefe de proyectos y consultor especializado en la metodología DSDM (método de desarrollo de sistemas dinámicos), representó al DSDM Consortium en la reunión.

– Alistair Cockburn: Americano. Creador de la familia de metodologías Crystal. Contribuyó a la expansión de la utilización de los casos de uso con la definición que hizo de los mismos en el libro “Escribir casos de uso efectivos” publicado en el año 2000, propiciando la generalización de su uso para describir el comportamiento de los requisitos software y de los procesos de negocio (a más alto nivel). La creación del concepto de caso de uso es bastante anterior, del año 1986 y fue realizada por el sueco Ivar Jacobson

– Ward Cunningham: Americano. Howard G. Cunningham fue el creador de la primera solución Wiki (WikiWikiWeb) y se considera un pionero tanto en la aplicación de programación extrema como en la utilización de patrones de diseño.

– Martin Fowler: Americano. Especialista en procesos de refactorización de software, programación orientada a objetos, UML y programación extrema. Hizo popular el uso del término “inyección de dependencias”.

– James Grenning: Americano. Especialista en sistemas empotrados. Fue uno de los pioneros en desarrollo de proyectos bajo la metodología de programación extrema. Experto en TDD (Test-driven Development). Ha sido el creador de la técnica de estimación Planning Poker.

– Jim Highsmith: Americano. James A. Highsmith III. Ingeniero de software experimentado que ha participado en proyectos de desarrollo de software en muchos países del mundo. En el año 1999 publicó el libro “Adaptative Software Development” donde puso de manifiesto la naturaleza adaptativa de los proyectos de desarrollo de software. Se ha especializado en la consultoría de proyectos que se realizan en entornos inestables y con una complejidad creciente.

– Andrew Hunt: Americano. Desarrollador de software con gran experiencia. Publicó junto a Dave Thomas en el año 1999 el libro “The Pragmatic Programmer”, en el que realizó una definición de lo que consideraban un programador práctico o pragmático:

– Early adopter.
– Curioso.
– Pensador crítico.
– Realista.
– Aprendiz de todo, maestro de nada.

Fue uno de los introductores en occidente de la programación en Ruby, mediante la publicación en el año 2000 del libro “Programming Ruby: A Pragmatic Programmer’s Guide”.

– Ron Jeffries: Considerado junto a Kent Beck y Ward Cunningham como uno de los creadores de la programación extrema. Participó junto a Beck en el proyecto de 1996 en Chrysler que dio lugar a este concepto.

– Brian Marick: Americano. Especialista en realización de tareas de testing. En el año 1995 publicó uno de sus libros más conocidos: “The Craft of Software Testing: Subsystem Testing Including Object-based and Object-oriented Testing”. Experto en Ruby.

– Robert C. Martin: Americano. Robert Cecil Martin (Uncle Bob). Dedicado a tareas de desarrollo de software desde 1970. Especialista en programación orientada a objetos sobre todo en el área de patrones de diseño.

– Steve Mellor: Americano. Especialista en sistemas empotrados, programación orientada a objetos y MDA (Model Driven Architecture). Creador junto a Sally Shlaer del método Shlaer-Mellor que es uno de los métodos de análisis y diseño orientado a objetos que surgió a finales de la década de los ochenta como respuesta a las principales problemáticas que presentaba el análisis y diseño estructurado, entre las cuales destacaban la complejidad de los diseños estructurados y la dificultad de mantener tanto su documentación de análisis como de diseño.

– Jon Kern: Americano. Inició su carrera profesional en sistemas empotrados en el área militar. Considerado como uno de los pioneros en la aplicación de la programación orientada a objetos. Especialista en programación Java y en MDA.

– Ken Schwaber y Jeff Sutherland: Americanos. Creadores de la metodología Scrum.

– Dave Thomas: Inglés. Autor junto a Andrew Hunt del libro “The Pragmatic Programmer”. También junto al mismo autor se considera uno de los introductores de Ruby en occidente.

Soy un converso, quizá por eso mi postura es más radical. Estoy cansado de participar en desarrollos con metodologías clásicas que no terminan de tener éxito (no tener éxito no es lo mismo que fracasar, aunque bastante de ellos sí que se podrían considerar un fracaso), podría ser algo que solo me pasara a mi, pero no es así, sucede con frecuencia y seguro que todos nosotros conocemos o hemos vivido proyectos con estos resultados.

La crisis del software sigue existiendo y existirá mientras no cambien muchas cosas. Los que nos dedicamos a esto tenemos muchos esquemas mentales que cambiar, son años haciendo los desarrollos de una determinada manera y también de formación centrada exclusivamente en metodologías clásicas.

El éxito o el fracaso de un proyecto no es exclusivo de las metodologías, pero sí predisponen a obtener unos resultados u otros.

Los proyectos de desarrollo de software tienen una naturaleza cambiante, es complicado acertar en todo: obtener los requisitos del usuario, la mecánica de comunicación entre usuario y sistema, la interfaz, etc… y lo es porque ni los usuarios tienen claro lo que quieren hasta que ven funcionalidades implementadas y también porque no siempre se interpreta adecuadamente por parte de los analistas o técnicos del proyecto las necesidades de los usuarios.

Metodologías de carácter eminentemente predictivo como las clásicas no son acordes con la naturaleza del desarrollo de software, habrá excepciones porque no existen llaves maestras que sirvan para todo.

Las metodologías ágiles, son adaptativas, son iterativas, incrementales. Sin embargo por encima de ellas está la propia filosofía del desarrollo ágil, realmente es la esencia, una vez entendida es mucho más trascendente que cualquier forma de llevarla a cabo.

Teniendo claro qué significa ser ágil, hasta su aplicación en metodologías clásicas las hace más flexibles.

En el año 2001 se reunieron en Salt Lake City diecisiete prestigiosos expertos en gestión de proyectos, ingeniería y desarrollo de software. La convocatoria la realizó Kent Beck, padre de la programación extrema.

En la reunión analizaron las problemáticas existentes en el desarrollo de software y en la necesidad de cambiar la forma en que se enfocaban y hacían los proyectos de desarrollo de software, lo cual dio lugar a unas conclusiones, recogidas en el manifiesto ágil.

En mi opinión, se trata de un manifiesto a favor del desarrollo de software, en su defensa, en la defensa de los que nos dedicamos a esta profesión ya que la mejor forma de dignificarnos es conseguir que la mayor parte de nuestros proyectos tengan éxito. Hay que romper con lo que no funciona, si el desarrollo de software es de una manera, actuar de otra es ir contra natura.

Los firmantes del manifiesto fueron las siguientes personas: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

El contenido del manifiesto es el siguiente, primero pongo el original en inglés y a continuación su traducción:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions over processes and tools.
– Working software over comprehensive documentation.
– Customer collaboration over contract negotiation.
– Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

“Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

– A los individuos y su interacción, por encima de los procesos y las herramientas.
– El software que funciona, por encima de la documentación exhaustiva.
– La colaboración con el cliente, por encima de la negociación contractual.
– La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.”

En el próximo artículo sobre esta materia comenzaré a exponer mi punto de vista sobre cada principio de los que componen el manifiesto.

Continuando con el estudio del grado de estabilidad (o inestabilidad) de un paquete en función de sus valores de acoplamiento y acoplamiento eferente, tal y como fueron enunciados por Robert Cecil Martin, toca establecer su relación con una de las características de la programación orientada a objetos como es la abstracción.

El mismo Robert Cecil Martin especificó que un paquete con una estabilidad máxima (o inestabilidad = 0) debería ser abstracto al máximo y que un paquete con estabilidad mínima tiene que ser concreto al máximo.

El razonamiento resulta lógico, ya que un paquete con inestabilidad 0 quiere decir que tiene no tiene acoplamiento eferente, es decir, no depende de ninguna clase de otro paquete y que como mucho tendrá valores de acoplamiento aferente o lo que es lo mismo hay clases de otro paquete que dependen de clases de este paquete, las cuales “fuerzan” a los desarrolladores a minimizar los cambios en el paquete por sus posibles consecuencias en dichas clases externas. ¿Cómo se consigue llevar la estabilidad a su máxima expresión? Pues forzando a que el mayor número de clases del paquete sean abstractas.

Recordemos que una clase abstracta es aquella que tiene al menos un método abstracto y que un método abstracto es aquel que solo presenta su especificación pero no su implementación. Una clase abstracta no puede ser instanciada y las clases que heredan de ella tienen que implementar los métodos abstractos definido en la superclase o volver a declararlos como abstractos, lo que daría lugar a que dicha subclase también sería abstracta.

El grado de abstracción de un paquete se define mediante la siguiente fórmula:

Abstracción = Clases Abstractas / (Clases Abstractas + Clases no Abstractas)

De esta manera, al igual que sucede con la inestabilidad, los valores de abstracción se encontrarán también en el rango de 0 a 1, de manera que tendremos el valor 1 cuando el paquete tenga todas las clases abstractas (o lo que es lo mismo no tenga clases no abstractas) y 0 cuando el paquete no tenga clases abstractas.

Robert Cecil Martin expone una relación interesante entre el grado de abstracción y el grado de estabilidad, pero como se puede apreciar ese grado se tiene que forzar, ya que ni la abstracción no la estabilidad son función del otro. Esto provoca que se puedan producir situaciones en cierto modo paradójicas como por ejemplo las siguientes:

– Inestabilidad = 1 y Abstracción = 1. Esto querría decir que nos encontramos con un paquete con clases de las cuales no depende ninguna clase de otro paquete y sin embargo todas las clases del paquete son abstractas y por tanto no instanciables. Esta situación es tan paradójica que será difícil de encontrar en un programa, ya que vendría a decir que no se estaría utilizando el paquete para nada.

– Inestabilidad = 0 y Abstracción = 0. En este caso nos encontramos con un paquete cuyas clases no dependen de ninguna clase de otro paquete y que además ninguna de sus clases es abstracta. Esta circunstancia es menos paradójica y por supuesto posible en un programa, vendría a hacer referencia a un paquete estable y concreto y por tanto rígido, siendo un paquete a vigilar si el acoplamiento aferente es alto, debido a que las posibilidades de efectos colaterales puede ser alta.

Tal y como enunció Robert Cecil Martin, los valores más deseables para cada paquete serían Inestabilidad = 1 y Abstracción = 0 e Inestabilidad = 0 y Abstracción = 1, no obstante, cualquier paquete que se encuentre en la recta que une ambos puntos se considera que tiene unos valores de estabilidad y abstracción compensados o equilibrados.

De lo anterior se puede deducir una nueva métrica que es la distancia de un paquete respecto a esa recta ideal, que se calcula mediante la siguiente fórmula:

D = ABS((Abstracción + Inestabilidad – 1) / SQRT(2))

devolviendo unos valores que se encontrarían en el rango entre 0 y 0’707, que indicarían que el paquete se encuentra sobre la recta o en el punto más extremo posible.

También hay cálculos de dicha distancia estableciendo el rango entre 0 y 1, aplicando la siguiente fórmula:

D = ABS(Abstracción + Inestabilidad – 1)

Por tanto, con lo estudiado en el anterior artículo y éste, basado en los enunciados de Robert Cecil Martin, es posible tener una serie de métricas que nos permitan servir de referencia a la hora de estudiar la calidad en el diseño de paquetes (y en general del diseño) de una determinada aplicación.

Otras métricas de calidad que resultan interesantes de estudiar están relacionadas con el cálculo de acoplamiento aferente (hacia dentro) y eferente (hacia afuera) de un paquete y la relación entre los mismos, dando lugar a una métrica resultado de ellas denominada inestabilidad de un paquete. Estas tres métricas fueron propuestas por Robert Cecil Martin aka “Uncle Bob” (más conocido posteriormente por liderar iniciativas orientadas a metodologías ágiles de desarrollo y programación extrema) en el año 1995.

Desde la perspectiva de un paquete concreto el acoplamiento aferente se produce cuando otro paquete hace uso de atributos y/o métodos de clases de dicho clase o hereda de alguna de ellas y el acoplamiento eferente se produce cuanto dicha clase hace uso de atributos y/o métodos de clases de otro paquete o hereda de clases de dicho paquete.

Por tanto el cálculo del acoplamiento aferente se obtiene mediante la suma de clases de otros paquetes que cumplen las características indicadas en el párrafo anterior y el acoplamiento eferente se obtiene como la suma de clases de otros paquetes de los cuales dependen clases del paquete con el que se está trabajando.

Como su propio nombre indica se trata de métricas de acoplamiento y como hemos estudiado previamente en las métricas de Chidamber y Kemerer, existe relación directa entre el acoplamiento, la complejidad, la mantenibilidad y la selección de clases (o paquetes) donde hay que prestar más atención a la hora de realizar las pruebas unitarias.

Un alto acoplamiento aferente hace referencia a un paquete con un alto grado de responsabilidad. La responsabilidad y la estabilidad son dos conceptos que suelen ir cogidos de la mano, precisamente porque al existir un elevado número de clases que dependen de clases del paquete, se tiene que ser necesariamente más prudente a la hora de realizar modificaciones en clases del paquete por los posibles efectos colaterales que se pueden producir. No obstante la estabilidad de un paquete no es función exclusivamente del acoplamiento aferente como veremos más adelante en la definición de inestabilidad.

Un alto acoplamiento eferente hace referencia a un paquete con un alto grado de dependencia. La dependencia y la inestabilidad son también dos conceptos íntimamente relacionados, ya que el funcionamiento de las clases del paquete dependen del comportamiento de clases externas, lo que las hace susceptibles de efectos colatarales en las modificaciones de las mismas y por tanto su funcionamiento entraña una mayor incertidumbre.

La inestabilidad de un paquete es la métrica que enfrenta entre sí al acoplamiento aferente y eferente a través de la siguiente fórmula:

Inestabilidad = Acoplamiento eferente / (Acoplamiento eferente + Acoplamiento aferente)

Por tanto los valores de inestabilidad se encontrarán dentro del rango de valores entre 0 y 1.

Estudiando los valores extremos podemos afirmar que si la inestabilidad de un paquete es 1 quiere decir que el acoplamiento aferente es 0 o lo que es lo mismo ninguna clase externa al paquete tiene una relación de dependencia respecto a una clase del paquete, por lo que el paquete sólo tiene dependencias hacia clases externas al paquete. El valor 1 indica una inestabilidad “extrema” del paquete (no obstante, habría que valorar también el valor individual del acoplamiento eferente, ya que, es una opinión personal mía, no todas las inestabilidad con valor 1 tendrían por qué ser iguales) ya que por un lado su comportamiento depende de clases externas, lo cual la hace posible víctima de efectos colaterales y por otro el hecho que no haya clases que dependan del paquete, da una mayor libertad a la hora de realizar modificaciones en el mismo ya que no hay que pensar en terceras clases a la hora de realizar modificaciones en el mismo (también habría que matizar esto, ya que puede haber dependencias entre clases del paquete, medibles mediantes distintas métricas, que provoquen que no sea tan ágil o sencillo modificar el paquete).

Si la inestabilidad es 0 quiere decir que el acoplamiento eferente es 0, lo que viene a decir que el paquete solo tiene responsabilidades y por tanto es menos proclive al cambio debido a que modificaciones en el mismo pueden tener repercusiones en clases externas.

Como la inestabilidad puede tomar cualquier valor entre 0 y 1, en función de a qué extremo se acerque más podemos darle una interpretación al resultado.