archivo

Archivo de la etiqueta: ingeniería del software

Responsibility-driven design es una técnica de diseño orientado a objetos propuesta por Rebecca J. Wirfs-Brock and Brian Wilkerson.

Rebecca J. Wirfs-Brock es una autora y consultora americana especializada en los ámbitos del diseño y programación orientada a objetos, con una gran experiencia desarrollada en diferentes empresas.

Brian Wilkerson es otro especialista en programación y diseño orientado a objetos, que ha desarrollado su carrera profesional en el mundo de la consultoría.

A principio de los 90 fueron coautores de los libros en los que formulaban esta técnica de diseño.

El diseño orientado a la responsabilidad se basa en dar respuesta para cada tipo de objeto a las siguientes preguntas:

– ¿De qué acciones es responsable el objeto?
– ¿Qué información comparte el objeto?

Proporcionando una alternativa a los diseños que consideraban a los objetos como datos y algoritmos. En este caso los objetos se consideran como la conjunción de roles y responsabilidades, los cuales conviven cooperando dentro de la aplicación.

Esta técnica de diseño está claramente inspirada en la mecánica de funcionamiento cliente/servidor, en la cual se define un contrato que rige el funcionamiento de los objetos implicados de manera que el cliente solo puede realizar los tipos de solicitudes/peticiones que se hayan definido y el servidor debe responder.

Es una técnica que también huye del conocimiento de los detalles de cómo un objeto realiza una acción u obtiene un resultado, fomentando de esta forma el concepto de encapsulamiento. Además, para reforzar esta cualidad, Wirfs-Brock y Wilkerson abogan por la existencia de un control de grano fino de visibilidad de los objetos.

No solo es una técnica que persigue el encapsulamiento sino la abstracción al ocultar, al menos en términos de diseño, la relación entre datos y comportamiento, ya que solo se debe pensar en responsabilidades a nivel de conocer, hacer y decidir.

En la técnica, por tanto, tendremos una comunidad de objetos que tienen asignadas responsabilidades específicas y que conforman un modelo colaborativo de funcionamiento en el que los mecanismos de colaboración están claramente definidos constituyendo de esta forma una arquitectura en la que existe un comportamiento distribuido.

De esta forma podemos realizar las siguientes definiciones:

¿Qué es una aplicación? Un conjunto de objetos que interactúan.
¿Qué es un objeto? La implementación de uno o más roles.
¿Qué es un rol? Un conjunto de responsabilidades
¿Qué es una responsabilidad? La obligación de realizar una tarea o de conocer un determinado tipo de información.
¿Qué es una colaboración? A la interección entre objetos y/o roles.

Tal y como se ha comentado anteriormente, esta técnica considera a los objetos como algo más que paquetes que solo encierran lógica y datos, ahora se en función de los roles que desempeñen a controladores, proveedores de servicios, titulares de información, interfaces con el exterior, etc…

Tan negativo resulta en un proyecto de desarrollo de software el exceso de documentación como la carencia de la misma.

La documentación debe ser adecuada a la naturaleza del software que se va a desarrollar y tener utilidad, como mínimo para el momento en que se está realizando el proyecto. Si se pierde el enfoque del momento presente y se centra en la utilidad futura que pueda tener la misma, puede que al final no sea útil ni después ni ahora.

La documentación de un proyecto es un instrumento, no un fin, de igual forma que lo es la ingeniería del software. Si la documentación es un objeto decorativo no es útil, es esfuerzo invertido para obtener muy poco valor a cambio.

Esa es mi opinión sobre la documentación, Edward Nash Yourdon, tiene la suya propia que hace patente en la siguiente reflexión, si bien, estoy seguro que el propio Yourdon matizaría sin duda la misma: “No hay nada más despreciable en el mundo de la programación que un programa sin documentar”.

Pamela Zave es una experta en ingeniería del software (especialmente en el campo de la ingeniería de requisitos) que lleva trabajando desde hace veinte años en AT&T. Ha escrito numerosos artículos, algunos de ellos galardonados con premios. Además es conferenciante y es miembro de importantes comités a nivel internacional.

Si la ingeniería del software añade complejidad a un proyecto de desarrollo de software es que no se está aplicando correctamente, no se sabe aplicar o ambas cosas. Como bien comenta Pamela Zave en la siguiente reflexión: “El propósito de la ingeniería del software es controlar la complejidad, no crearla” y está totalmente en lo cierto.

La ingeniería del software es un instrumento, no un fin, que bien utilizado permite desarrollar software de calidad, aplicando la metodología más adecuada para el proyecto en cuestión, gestionando adecuadamente las personas que intervienen en el mismo y existiendo unos plazos y presupuestos acordes a los objetivos planteados.

Grady Booch es conocido por ser el creador de UML junto a Ivar Jacobson y James Rumbaugh. Es un especialista en el campo de la ingeniería del software más concretamente en el campo de la metodología y del diseño de patrones.

Es la actualidad es director científico de Rational Rose y socio de IBM y ha sido autor de libros y de numerosos artículos.

La ingeniería del software es método y técnica a la que se saca brillo a través de la experiencia. No hay nada al azar, todo tiene un sentido y un cometido. Por ese motivo, Grady Booch tiene mucha razón cuando realiza la siguiente reflexión: “Un ingeniero de software aficionado está siempre en búsqueda de la magia”.

Sam Redwine es un experto en los campos de la ingeniería del software y de la seguridad del software. Es profesor universitario, pertenece a organismos prestigiosos relacionados con la seguridad del software, es articulista y conferenciante.

Su siguiente reflexión es del año 1988 y resulta significativo que 23 años después todavía se produzca el mismo problema: “El software y las catedrales son muy similares. Primeros los construimos, después rezamos”.

Es curioso como la tecnología ha avanzado vertiginosamente en todos estos años y muchas de ellas son de uso común en la mayoría de las empresas de desarrollo de software, sin embargo, en el ámbito metodológico la aplicación, en proporción con los avances tecnológicos, ha sido escasa.

Si las cosas se hacen bien, no habría necesidad hoy día de cruzar los dedos cuando se entrega un software. Claro que habrá errores que se escapen y lleguen a producción (su criticidad dependerá de la naturaleza de los mismos y del sistema), pero existe la posibilidad de, aplicando buenas prácticas en el proceso de desarrollo, colaborando con los usuarios y haciendo un buen proceso de testing de intentar minimizar los errores que llegan hasta el usuario final y que estos sean los menos graves posibles.

David (Dave) Lorge Parnas es un profesional canadiense pionero en el campo de la ingeniería del software de la cual ha sido un ferviente defensor a lo largo de su carrera. Ha recibido numerosos premios a lo largo de su carrera y ha sido profesor en universidades de diferentes países del mundo.

El desarrollo de software se realiza para organizaciones que están en continuo movimiento: puede cambiar el mercado, los procesos, los usuarios, los responsables técnicos, etc…, a lo que hay que sumar que se intentan abstraer procesos que se realizan en el mundo real a un programa de ordenador y no es nada fácil ese proceso porque los que definen el sistema no tienen claro, por regla general, lo que quieren realmente (tienen una idea, pero hasta que no la ven reflejada, no terminan por matizarla).

La naturaleza del software es adaptativa, mediante aproximaciones y evoluciones se consiguen alcanzar productos que satisfacen las necesidades del usuario, a través del feedback que se obtiene de los mismos una vez que hacen uso del sistema. Los principios ágiles definen ese marco (que también se tiene en cuenta en metodologías del proceso unificado como RUP), si bien, nuestra propia experiencia personal nos dirigirá de alguna u otra forma y de forma paulatina hacia enfoques iterativos e incrementales en lugar de ciclos de vida clásico o en cascada.

Dave Parnas, sobre este tema realiza la siguiente reflexión (traducción libre): “Por regla general, los sistemas software no funcionan adecuadamente hasta que han sido utilizados y han fallado repetidamente en entornos reales”.

Son muchos autores los que consideran que la búsqueda de la solución perfecta en el desarrollo de software requiere de un esfuerzo exponencialmente superior al necesario para conseguir una buena solución, teniendo en cuenta además que la perfección es un concepto abstracto y que no se va a terminar de conseguir nunca.

En los proyectos desarrollo de software hay que buscar lo práctico, la Ley de Pareto es una regla muy útil y que debemos tener siempre en cuenta.

Otra regla muy interesante es la Ley de Parkinson en la que se indica que siempre que el proyecto esté abierto se tenderán a hacer tareas independientemente de la utilidad real de las mismas.

Otra referencia, la tenemos en el Principio 90-90 o de Cargill que al fin y al cabo es una versión de la Ley de Pareto adaptada al desarrollo de software.

Una solución “perfecta” requiere en muchos casos la introducción de una complejidad técnica y o funcional en el software que provocará precisamente el efecto contrario al que se está buscando. Es necesario huir de la complejidad o por lo menos de toda aquella que no sea necesaria para conseguir un producto que satisfaga las expectativas del usuario. David Gelernter define muy bien esta situación cuando comenta que: “La belleza es la última defensa contra la complejidad”.

La ingeniería del software no busca desarrollos perfectos sino que busca proyectos bien ejecutados. Los principios y metodologías ágiles persiguen lo mismo.

Bjarne Däcker, es un profesional que se merece todos mis respectos, empezó como programador en Ericsson en 1966, por lo que lleva 45 años en este negocio y es por ejemplo miembro de la Real Academia Sueca de Ciencias de la Ingeniría, sin embargo no estoy de acuerdo con su siguiente cita: “Un sistema software debería ser como una sinfonía de Mozart: Perfección en todos los niveles”.

Tal vez la ejecución final deseable de un sistema de información debería ser esa e incluso hay aplicaciones que gestionan sistemas críticos (aquellos en los que un fallo puede provocar pérdida de vidas o poner en peligro la continuidad de una organización) donde la calidad exigible a los resultados es muy alta.

Sin embargo, la búsqueda de esa perfección por sistema puede provocar que el proyecto entre en una espiral donde no salga beneficiado nadie.