Metodología orientada a desarrollo con equipos reducidos (MODER)

a. ASPECTOS IMPORTANTES DE MODER

Antes de realizar una descripción detallada de la metodología MODER, se mencionan a varios aspectos importantes entre los cuales está el manifiesto por el desarrollo ágil de software que apareció luego del encuentro de los principales exponentes de los métodos agiles, citados el 17 de febrero de 2001 por Beck Kent con la finalidad de unificar los principios fundamentales compartidos entre los diferentes procesos para mejorar el desarrollo ágil y que sirvan como una guía para cualquier metodología que pueda considerarse de esta forma.

También se pone énfasis en los dos enfoques de desarrollo de software que son el de Burocracia, representado por organizaciones con procesos disciplinados y definidos hasta el mínimo detalle y la Adhocracia que muestra un desarrollo caótico sin conocer procesos

39

ni a donde va el proyecto, por lo que se puede decir que en un extremo se muestra un proceso claro y definido que no satisface las necesidades del usuario y al otro lado se muestra la oscuridad y aleatoriedad del caos, obteniendo beneficios o pérdidas a corto plazo.

Por lo tanto el Modelo Cascada representa el régimen burocrático en el cual los proyectos se planifican acorde que realizaran los recursos, impulsa el orden de la organización mediante la división en etapas, así también se encuentra la metodología RUP que es un proceso muy utilizado actualmente, este construye artefactos especificados y realizando todas las actividades planteadas, en otras palabras, estos procesos intentan definir las actividades, roles, entregables y otros aspectos del proyecto de software para obtener resultados predecibles a lo largo del tiempo.

En cambio sí se dirige al caos, se encuentran los métodos ágiles, mismos que reconocen la complejidad del software, en estos métodos, las personas son las más importantes por lo tanto sacrifican el proceso a cambio de brindar libertad a los individuos ya que se los reconoce como elementos de primer orden totalmente necesarios, por lo que solo proponen una guía en el desarrollo hacia un objetivo que puede no permanecer constante en el tiempo a medida que aumenta el conocimiento de la aplicación que se construye, aunque esto no significa que se llega al proceso de Codificar y Probar.

A continuación se muestra la división entre la Burocracia y la Adhocracia y donde se encuentran varias de las metodologías que se usan actualmente

Figura 11. Ubicación de las metodologías en relación al nivel de formalidad. Fuente. ESTELLER, Víctor, (2011),” Procesos de desarrollo de software y materiales educativos computarizados”.

Otro de los aspectos importantes a tomar en cuenta es la cantidad de personas participantes en el desarrollo de software, ya que en muchas ocasiones se piensa que a más personas se

40

incrementa al proyecto se debe aplicar una metodología pesada, aunque muchas veces esto no es una buena solución porque implica que los nuevos integrantes debe conocer un proceso que ya se encuentra adelantado y al contrario se debe invertir más recursos sea económicos como de tiempo.

MODER se enfoca a grupos de trabajo reducidos, que en el caso de Uniandes va desde uno a cuatro integrantes, aunque esto tampoco quiere decir que no se pueda aumentar más personas para que lleven a cabo los respectivos roles que les pueda asignar a cada uno de ellos, aunque para MODER el número máximo de integrantes del equipo de desarrollo es de ocho personas por lo que deben tener una buena comunicación y ambiente de trabajo, aunque para estos casos, los más recomendable seria separar en dos equipos de cuatro personas cada uno con la finalidad de tener más comodidad y mejor comunicación, a más de esto se debe tener en cuenta el alcance y dificultad del proyecto a realizar, al ser una metodología ágil se recomienda para proyectos de mediana complejidad para de esta forma asegurar la calidad del software.

A continuación se presenta una gráfica que muestra con el aumento de la criticidad se pierde el confort.

Figura 12. Relación número de personas, criticidad y tamaño de la metodología. Fuente. COCKBURN, Alistair, (2001),”Agile Software Development”.

De acuerdo a la figura doce, MODER se puede aplicar en proyectos de características C3, C10, D3, que tienen como un mínimo de seis a un máximo veinte personas en el equipo de desarrollo ya que muestra una baja criticidad, pérdida de confort o viabilidad económica.

MODER pone énfasis en la orientación a personas porque se consideran como componentes de primera magnitud en cualquier desarrollo ágil, por lo tanto se cumple el

41

primer valor del manifiesto de agilidad que dice: “Individuos e Interacciones por sobre procesos y herramientas” (Beck, 2001), a diferencia de la orientación al proceso que propone etapas y roles bien definidos, dejando en segundo plano a las personas ya que si se tiene un proceso predecible bien definido, el éxito estaba garantizado independientemente de las personas que cubrieran los roles.

Una vez que se ha puesto en conocimiento varios aspectos importantes en los que se debería asentar la Metodología MODER, se pasa a realizar la respectiva descripción de la misma, mostrando su roles, fases, actividades, entre otros conceptos que permitan conocer de cerca el presente trabajo.

b. DESARROLLO DE LA METODOLOGÍA MODER

Durante el desarrollo de la presente investigación se ha hecho mención a varios asuntos de gran importancia dentro de la ingeniería de software, misma que permite llevar a cabo el proceso de desarrollo de software, su propósito y ventajas que trae dentro de una organización.

A más de esto se ha realizado una investigación de las diferentes metodologías que más se usan en la actualidad, tomando en cuenta varias de las llamadas metodologías ágiles así como también las metodologías pesadas mostrando los aspectos más relevantes e importantes de cada una de ellas.

En el caso de Uniandes Ibarra, se pudo comprobar que la metodología RUP no es adecuada para desarrollo de software con equipos de trabajo reducidos determinados por la institución, porque según la entrevista realizada al Ing. Luis Suárez, manifestó que esta es una metodología que no se acopla a la realidad de los proyectos integradores de la institución, en cuanto a la metodología XP, según el Ing. Luis Suárez, los modelos ágiles son los que mejor adaptabilidad tienen a los proyectos de Uniandes y por lo tanto se determinó que puede ser una opción viable pero aún es necesario poner mayor énfasis en el aprendizaje y difusión de la misma, con la finalidad de obtener mejores resultados en el desarrollo de los proyectos.

En el desarrollo de esta propuesta, se tomó en cuentan el trabajo con grupos reducidos de personas sin tener la necesidad de realizar costosas inversiones en herramientas o que sea demasiado complicado la aplicación de MODER, ya que la finalidad es minimizar la burocracia que conlleva a utilizar procesos complejos que gastan demasiados recursos,

42

pero esto no quita que se realice un software de alta calidad a pesar de las limitaciones que se presentan con los grupos de trabajo reducidos.

Según Alistair Cockburn (Cockburn, Agile software development, 2000, p. 102), se necesitan 10 elementos que intervienen dentro de las metodologías agiles de desarrollo, las cuales son: roles, destrezas, entregables, actividades, valores, equipos, asignación de tareas, técnicas, herramientas, estándares.

Técnicas: Las técnicas que las personas deben utilizar en su trabajo. Por ejemplo: TDD. Estándares: Lo que se permite o no, aquí se incluye notación, acuerdos del proyecto y de calidad.

Herramientas: Las herramientas que las personas usan a diario ya sea dentro de una técnica o para realizar una actividad en concreto.

Valores: Los valores del equipo y de la propia metodología.

Roles: Son las descripciones de los trabajos que las persona deben cumplir. Ejemplo: programador, analista, etc.

Actividades: Las actividades e hitos se integran para crear los entregables finales.

Destrezas: Es la capacidad para hacer una cosa bien, con facilidad y rapidez a fin de llevar a cabo el proyecto. Ejemplo: Hábil en el manejo de herramientas.

Entregables: Son los documentos que cada persona o equipo entregue a otra persona o equipo. Ejemplo documentación de requerimientos.

Equipos: La forma en que se agrupan a las personas.

43 b.1. TÉCNICAS

A continuación de exponen algunas técnicas que podrían ser utilizadas por el equipo para tener una mejor organización para el proyecto, así como el trabajo a nivel de código, también se hace referencia a que estas son opcionales y el equipo decidirá si aplica o no.

b.1.1. PROGRAMACIÓN EN PAREJAS

El software se escribe en parejas, es decir dos programadores en una misma computadora, con la finalidad de generar un mejor código, pruebas, diseños, a más de ayudar en la productividad y compartir conocimientos entres los programadores.

b.1.2. TDD (DESARROLLO GUIADO POR PRUEBAS)

Esto quiere decir que se debe realizar primero la prueba antes de escribir el código funcional con la finalidad de generar un buen código además que está probado, esto ayudará cuando se necesite hacer cambios en funcionalidades ya desarrolladas, con esto se sabrá donde se generaron errores por los cambios realizados.

b.1.3. REFACTORING

Esta técnica permitirá eliminar el código duplicado y también el código que ya se escribió y es funcional, esto tiene la finalidad de mejorar y optimizar el software, además de facilitar el mantenimiento a lo largo del tiempo y según se incremente el software.

b.2. ESTÁNDARES

Los estándares pueden ser definidos por los involucrados en el proyecto, aunque se podrá en consideración algunas de estas, no con la intención que sea obligatorio su uso sino como una referencia, con esto el equipo tenga la libertad de decisión para aplicarlas o no de acuerdo a sus necesidades.

b.2.1. CÓDIGO LIMPIO

Aquí se pone énfasis al código que sea entendible para cualquier programador, inclusive si este no ha participado en el proyecto, la idea principal de esto es escribir un código legible, esto también ayudará en el mantenimiento del software.

44

b.2.2. ESTÁNDARES DE CÓDIGO DEFINIDOS POR EL EQUIPO

Es importante ya que de código se escribe de una forma común para todos los programadores, de manera que el código del sistema se vea como si fuera escrito por una única persona, no importa mucho el estándar, lo que realmente interesa es que el código se vea familiar para todos.

Pueden utilizar la notación camel case o underscore para escribir el nombre de las funciones.

b.3. HERRAMIENTAS

En el caso de las herramientas, esto dependerá de la tecnología que se vaya a utilizar y el tipo de aplicación a desarrollar, pero como recomendación se pone a disposición un conjunto estas, no con la intención de que su utilización sea obligatorio, sino que sirva como una guía de referencia ya que el equipo puede escoger las que crea necesarias, útiles y que se adapten a sus necesidades.

b.3.1. GIT

Esta es una herramienta diseñada para el manejo de versiones del código fuente, es muy útil para trabajar en equipos.

b.3.2. TEST UNITARIOS

Para crear los test unitarios existen muchas herramientas útiles que ayudan a automatizarlos, aunque depende de la tecnología utilizada, pero se mencionan algunas suites de testing:

 JUnit para Java

 CodeCeption para PHP  Jazmin para JavaScript

b.3.3. GESTIÓN DE PROYECTO

Para la gestión y asignación de tareas, también se presentan un par de opciones que son de mucha ayuda para llevar un control más detallado de lo que se está haciendo.

45  Kunagi

 Redmine

b.4. VALORES

b.4.1. COMUNICACIÓN

La comunicación entre los miembros del equipo es fundamental, el diálogo frontal entre desarrolladores, institución y todas las personas participantes es el medio básico de comunicación. Una buena comunicación tiene que estar presente durante todo el proyecto.

b.4.2. SIMPLICIDAD

Hacer exactamente lo que se ha pedido, no más que eso, ya que los objetivos se alcanzan con pasos simples y pequeños, reduciendo las fallas a medida que ocurran.

b.4.3. RETROALIMENTACIÓN O FEEDBACK

Siempre tener en cuenta la valoración de la institución beneficiaria una vez que se hace la entrega e intentar mejorar haciendo cambios en el proceso si es necesario.

b.4.4. RESPETO

Todos los miembros del equipo dan y reciben el respeto como integrantes del mismo, así también se valoran los aportes de cada integrante.

b.5. ROLES, ACTIVIDADES Y DESTREZAS

Antes de realizar la descripción de cada uno de los roles que se incluyen en MODER, se hace una referencia a que una persona puede cumplir más de un rol dentro del desarrollo de software utilizando MODER, sin que este conlleve a mayores dificultades.

Cabe mencionar también que varios de los roles son cumplidos por personas externas al grupo de desarrollo y que están vinculadas directamente con el beneficiario y son las encargadas de brindar el conocimiento del negocio.

b.5.1. INSTITUCIÓN O EMPRESA DONDE SE REALIZA EL PROYECTO.

Puede ser cualquier organización pública o privada que será la beneficiaria del proyecto que se va a desarrollar.

46 Actividades

 Define el proyecto y sus objetivos.

 Se encarga del soporte gerencial del proyecto, es decir provee, comunica y mantiene actualizada la visión del proyecto.

 Entrega el presupuesto para dar la viabilidad económica del desarrollo.

 Es responsable por la consecución del proyecto del lado de la institución beneficiaria.

Importancia del rol

Es esencial para el éxito del proyecto ya que si un software no tiene aceptación en una organización, este no llegará a ser construido.

b.5.2. LÍDER DE PROYECTO

Integrante del equipo estudiantil que está a cargo del proyecto, y apoya como vínculo entre el equipo de desarrollo y la institución o empresa beneficiaria.

Actividades

 Se encargará de la planificación del proyecto y de los detalles de cada iteración.  Asigna recursos y encarga responsabilidades a los participantes del proyecto.  Promueve la unión del grupo y trata de eliminar fricciones.

 Organiza las reuniones que sean necesarias.

 Revisa constantemente el avance del proyecto y establece las estrategias para reducir los riesgos que se puedan presentar.

Importancia del rol

Este representa al equipo de desarrollo por lo tanto se convierte en el vínculo entre la gerencia y el equipo de desarrollo.

Destrezas

Debe conocer a fondo el negocio a más de tener un amplio conocimiento en gestión de proyectos, también debe tener una buena comunicación con el equipo de desarrollo y estar siempre atento a cualquier cambio que se presente.

47 b.5.3. EXPERTO EN EL NEGOCIO

Integrante del equipo estudiantil que asiste a las reuniones con la institución beneficiaria del proyecto con la finalidad de adquirir el conocimiento del negocio y luego transmitirlo al resto del equipo.

Actividades

 Brinda su conocimiento del negocio apoyando al modelado del sistema conjuntamente con los analistas.

 Participa con el tester en el desarrollo de las pruebas funcionales que se realizaran.  Da aprobación de las pruebas de aceptación por cada release entregado.

Importancia del rol

Ayuda al equipo de desarrollo a conocer el negocio para el cual está construyendo la aplicación, por lo tanto resuelve cualquier duda sobre el funcionamiento del sistema junto con los analistas.

Destrezas

Conocer a fondo el negocio para dar solución a cualquier duda que pueda surgir. Debe ser miembro de la empresa beneficiaria.

b.5.4. ANALISTA DE SISTEMAS

Integrante del equipo estudiantil que recibe los conocimientos del negocio por parte del experto del dominio con la finalidad de transformarlos en requerimientos de la aplicación que se van a desarrollar.

Actividades

 Recolecta la información con la finalidad de obtener los requerimientos de la aplicación que serán construidos en cada iteración.

 Desarrolla la especificación de los requerimientos.  Elabora el documento de Visión.

48 Importancia del rol

El aprendizaje de la aplicación y sus requerimientos son claves para el éxito del proyecto y la aceptación de los mismos por parte del usuario.

Destrezas

Debe tener amplio conocimiento de técnicas levantamiento y recolección de información.

b.5.5. ARQUITECTO DE SISTEMAS

Integrante del equipo estudiantil encargado de planificar los elementos individuales del sistema y diseñar la arquitectura del mismo, es decir se encarga de parte técnica del desarrollo.

Actividades

 Define la arquitectura que servirá para el desarrollo y su continuo refinamiento en cada iteración.

 Construye algún prototipo para probar aspectos de riesgo desde el punto de vista técnico del proyecto.

 Define los lineamientos generales del diseño y la implementación.

Importancia del rol

La arquitectura es necesaria en los proyectos de software por lo que al arquitecto es experto en la parte técnica del desarrollo y debe informar al equipo sobre los lineamientos de la construcción de la aplicación.

Destrezas

Debe tener buena formación técnica, experiencia en las herramientas y técnicas utilizadas, además de buena comunicación con la finalidad de comunica la arquitectura a todo el equipo, también debe alcanzar conseguir los hitos técnicos planteados mediante entregables para asegurar el progreso del desarrollo.

49 b.5.6. PROGRAMADOR O DESARROLLADOR

Integrante del equipo estudiantil que escribe, depura y mantiene el código fuente de un programa informático, es decir implementa algoritmos mediante un lenguaje de programación para solucionar algún problema determinado.

Actividades

 Realiza la codificación de los componentes a desarrollar en la iteración.  Desarrollar la base de datos para la aplicación.

 Crear y ejecutar los test unitarios sobre el código desarrollado.  Documentar y actualizar todas las clases que ha desarrollado.  Realizar la estimación de las tareas que se incluirán en el sprint.

Importancia del rol

Implementa las historias de usuario en el lenguaje de programación elegido para el desarrollo del proyecto, se encarga de definir las clases y métodos que cumplan los requerimientos del usuario.

Destrezas

Amplio conocimiento en diferentes lenguajes de programación y motores de base de datos así como también de frameworks que le ayuden en el desarrollo de su trabajo.

b.5.7. TESTER

Integrante del equipo estudiantil que se dedica a realizar pruebas a nuevas aplicaciones o a modificaciones de aplicaciones existentes con la finalidad de que al momento en que se pongan en operación el usuario no tenga problemas con la misma.

Actividades

 Se encarga de generar las pruebas funcionales a partir de los requerimientos obtenidos por los analistas.

50 Importancia del rol

Se centra en la necesidad de construir un software de calidad que cubra los requerimientos del usuario, aplicando un proceso que permita garantizar la calidad del producto desde el punto de vista técnico, por lo tanto el tester crea, ejecuta, analiza y mantiene las pruebas que se van a utilizar.

Destrezas

Debe tener conocimientos en técnicas de testing a más de conocer completamente toda la aplicación, así también debe tener conocimientos de programación para trabajar con las pruebas automatizadas.

c. FASES E HITOS

Como todas las metodologías utilizadas actualmente, MODER está conformada por un conjunto de fases las cuales son llevadas a cabo a lo largo del tiempo conformando así un período de tiempo que contiene hitos significativos por lo que en las primeras iteraciones del proyecto se analiza la viabilidad de ejecución del mismo y finaliza obteniendo la arquitectura con los riesgos más críticos mitigados, también se pone énfasis en la fase de construcción donde se genera el código fuente, con esto se pone a consideración que el grado de creatividad requerido en el proceso disminuye con el tiempo haciéndose un ciclo más predecible y fácil de seguir.

Figura 13. Fases de MODER. Fuente. Autor c.1. FASE DE ANÁLISIS

Para la fase de análisis se la dividirá en dos partes ya que en Uniandes Ibarra se requiere realizar el perfil del proyecto integrador o de tesis antes de la ejecución del mismo, por lo que la primera parte se llamará análisis previo y tendrá como objetivo obtener el

In document Metodología de desarrollo de software dirigida a equipos de trabajo reducidos para su aplicación en los proyectos integradores y tesis en Uniandes Extensión Ibarra (página 50-79)