Nuevas tecnologías y metodologías en la gestión y desarrollo.

Nuevas tecnologías y metodologías en la gestión y desarrollo

INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA (CASE)

Es el nombre que se le da al software que se utiliza para ayudar a las actividades del proceso del software como la ingeniería de requerimientos, el diseño, el desarrollo de programas y las pruebas. Por lo tanto, las herramientas CASE incluyen editores de diseño, diccionarios de datos, compiladores, depuradores, herramientas de construcción de sistemas, etcétera.

La tecnología CASE proporciona ayuda al proceso del software automatizando algunas de sus actividades, así como proporcionando información acerca del software en desarrollo. Algunos ejemplos de las actividades que se pueden automatizar utilizando CASE son:

1. El desarrollo de modelos gráficos del sistema como parte de la especificación de requerimientos o del diseño de software.

2. La comprensión del diseño utilizando un diccionario de datos que tiene información sobre las entidades y relaciones del diseño.

3. La generación de interfaces de usuario a partir de la descripción gráfica de la interfaz que es elaborada de forma interactiva por el usuario.

4. La depuración de programas por medio de la provisión de la información proporcionada por los programas en ejecución.

5. La conversión automática de programas de una versión anterior de un lenguaje de

programación, como COBOL, a una versión más reciente.

La tecnología CASE está disponible para la mayoría de las actividades rutinarias en el proceso del software. Esto permite algunas mejoras en la calidad y productividad del software, aunque éstas sean menores que las predichas por los primeros partidarios de CASE. Éstos sugirieron que se tendría una mejora mayor si se utilizan entornos CASE integrados. En realidad, las mejoras reales son del 40% (Huff, 1992). Aunque esto es significante, las predicciones que se hicieron cuando se introdujeron las herramientas CASE en los años 80 y 90 fueron que el uso de la tecnología CASE generaría enormes ahorros en los costos del proceso del software.

Las mejoras por la utilización de CASE están limitadas por dos factores:

1. Esencialmente, la ingeniería del software es una actividad de diseño que se basa en la creatividad. Los sistemas CASE automatizan las actividades rutinarias, pero los intentos de utilizar la inteligencia artificial para proporcionar ayuda al diseño no han tenido éxito.

2. En la mayoría de las organizaciones, la ingeniería del software es una actividad de equipo, y los ingenieros invierten mucho tiempo interactuando con los otros miembros del equipo. La tecnología CASE no proporciona mucha ayuda para esto.

Entre las herramientas CASE más comunes encontramos:

Herramientas de generación semiautomática de código (IDE).
Editores UML.
Herramientas de Refactorización de código.
Herramientas de mantenimiento como los sistemas de control de versiones.

Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes.

Los IDEs están compuestos por los siguientes componentes:

Un editor de texto.
Un compilador.
Un intérprete.
Un depurador.
Posibilidad de ofrecer un sistema de control de versiones.
Factibilidad para ayuda en la construcción de interfaces gráficas de usuario.

Algunos ejemplos más conocidos de IDEs son:

Netbeans
Microsoft Visual Studio
Eclipse
Qt Creator

LENGUAJES DE CUARTA GENERACION

Es el nombre con el que se le conoce a ciertas herramientas que permiten construir software con piezas prefabricadas. Sin embargo actualmente se piensa que estas herramientas no son propiamente un lenguaje, reservando el nombre para los lenguajes orientados a objetos. Se creó con la idea principal del desarrollo de aplicaciones comerciales, y con la meta de poder alcanzar un mayor nivel de abstracción, incluyendo una futura quinta generación (inteligencia artificial).

Todos los lenguajes de cuarta generación fueron diseñados para reducir el esfuerzo de programación, el tiempo que toma el desarrollo de un software y el costo de desarrollo. Sin embargo no siempre son exitosos en esta tarea, resultando algunas veces en código poco elegante e inmantenible.

Existen distintos tipos de lenguajes de cuarta generación:

Lenguajes de presentación, como lenguajes de consultas y generadores de informes.

Lenguajes especializados, como hojas de cálculo y lenguajes de bases de datos.

Generadores de aplicaciones que definen, insertan, actualizan y obtienen datos de la base de datos.

Lenguajes de muy alto nivel que se utilizan para generar el código de la aplicación.

Entre algunos lenguajes de cuarta generación conocidos se encuentran: PowerBuilder, WinDev, SQL, oracle reports, GeneXus, Coldfusion.

DESARROLLO AGIL

El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos iterativos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas. El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas funcionalidades al sistema. Aunque existen muchos enfoques para el desarrollo rápido de software, comparten las mismas características fundamentales:

1, Los procesos de especificación, diseño e implementación son concurrentes. No existe una especificación del sistema detallada, y la documentación del diseño se minimiza o es generada automáticamente por el entorno de programación utilizado para implementar el sistema. El documento de requerimientos del usuario define solamente las características más importantes del sistema.

2. El sistema se desarrolla en una serie de incrementos. Los usuarios finales y otros stakeholders del sistema participan en la especificación y evaluación de cada incremento. Pueden proponer cambios en el software y nuevos requerimientos que se deben implementar en un incremento posterior del sistema.

3. A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colando iconos en la interfaz. El sistema puede generar una interfaz basada en web para un navegador o una interfaz para una plataforma específica como Microsoft Windows.

Las dos ventajas principales de adoptar un enfoque incremental para el desarrollo del software son:

1. Entrega acelerada de los servicios del cliente. En los incrementos iniciales del sistema se pueden entregar las funcionalidades de alta prioridad para que los clientes puedan aprovechar el sistema desde el principio de su desarrollo. Los clientes pueden ver sus requerimientos en la práctica y especificar cambios a incorporar en entregas posteriores del sistema.

2. Compromiso del cliente con el sistema. Los usuarios del sistema tienen que estar implicados en el proceso de desarrollo incremental debido a que tienen que proporcionar retroalimentación sobre los incrementos entregados al equipo de desarrollo. Su participación no sólo significa que es más probable que el sistema cumpla sus requerimientos, sino que también los usuarios finales del sistema tienen que hacer un compromiso con él y conseguir que éste llegue a funcionar.

Entre algunos de los métodos de desarrollo ágil mas conocidos están:

SCRUM

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.⁴ Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Scrum tiene varios tipos de reuniones:

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)
Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Scrum de Scrum

Cada día normalmente después del “Daily Scrum”

Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.

La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:

¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.

Seleccionar qué trabajo se hará
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como límite

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”

Reunión de Revisión del Sprint (Sprint Review Meeting)

Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias “demo”)
El trabajo incompleto no puede ser demostrado
Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retrospective)

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Programación Extrema XP

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:

Simplicidad: La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.

Comunicación: La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

Coraje o valentía: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas aproximaciones.

Respeto: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, sino orientándolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

Características fundamentales

Las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit.

Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.

Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.