Trabajo de investigación realizado para la asignatura de Entornos de Desarrollo del ciclo Diseño de Aplicaciones Web cursado en el IES Camp de Morvedre (Sagunto)
ESTRATEGIA DE COMPOSICIÓN Y ORGANIZACIÓN DE UN EQUIPO DE DESARROLLO Y MANTENIMIENTO DE APLICACIONES WEB
2. ESTRUCTURAS DE ORGANIZACIÓN DE EQUIPOS DE TRABAJO
3. FORMACIÓN DE EQUIPOS DE TRABAJO
4. ETAPAS Y MODELOS DE DESARROLLO DE SOFTWARE
5. ROLES DE UN EQUIPO DE TRABAJO DE DESARROLLO DE SOFTWARE
6. CONCLUSIÓN.
7. REFERENCIAS
1.- INTRODUCCIÓN
El desarrollo de software y, por extensión, el de aplicaciones web es una actividad que requiere del cumplimiento de diversas facetas y del conocimiento de distintas tareas tanto relacionadas con la informática como no. Para la consecución de un proyecto de desarrollo de software deben conjugarse aspectos que abarcan la gestión, la dirección, la comunicación, la creatividad así como aspectos comerciales además de los puramente relacionados con el software como la programación o el diseño de aplicaciones. Todo ello sumado, por regla general, a una cantidad significativa de horas de trabajo, por lo que, ante esta exigencia, en la mayoría de casos se hace casi imprescindible para la consecución de objetivos realizar el trabajo de desarrollo de software en equipo.
Por tanto, excepto en proyectos de poca entidad o de características especiales, será necesario conformar un equipo de trabajo en el cual se distribuyan las distintas tareas, lo que exigirá un nivel importante de coordinación de los trabajos para lo que será necesario partir de una estructura de grupo sólida que permita la resolución de conflictos e incidencias de manera eficiente y con unos roles bien definidos y para los que se haya realizado una clara asignación de responsabilidades.
La consecución de objetivos dependerá en gran medida del trabajo de cada miembro del equipo pero también de la relación entre ellos y el cómo esté organizado el funcionamiento interno del grupo. Un equipo de trabajo formado por personas capacitadas puede fracasar si no se realiza un esquema de trabajo adecuado y un reparto de roles que se adapte a las exigencias del proyecto. Para ello a continuación se tratará de exponer las opciones de organización más comunes así como algunas directrices orientativas para la formación de equipos de trabajo eficientes.
2. ESTRUCTURAS DE ORGANIZACIÓN DE EQUIPOS DE TRABAJO
En las labores de investigación y desarrollo se han definido teóricamente cuatro modelos de organización de grupos o equipos de trabajo: modelo jerárquico, modelo adaptativo, modelo libre y modelo sincrónico. Y como resultado de su combinación puede considerarse un quinto modelo, el abierto, del que hablaremos más adelante.
Modelo Jerárquico: Es la estructura de esquema más simple y a su vez más antigua, basada en el principio de autoridad lineal según el cual los niveles superiores son obedecidos por sus respectivos niveles inferiores. Generalmente corresponde a una estructura piramidal, con una figura de autoridad que se sitúa en el nivel superior y que realiza las tareas de supervisión y toma de decisiones finales.
Es un modelo que se caracteriza por:
- Estructura estable y con roles bien definidos para cada nivel.
- Control estricto mediante el establecimiento de procedimientos de trabajo basados en directivas.
- Las decisiones de un nivel superior se convierten en directivas a cumplir por los niveles inferiores.
- La comunicación de la información está canalizada a través de las líneas jerárquicas que unen los distintos niveles.
- Los resultados son predecibles y programables.
Promueve los siguientes valores:
- Lealtad al grupo y a sus intereses, las actitudes críticas e independientes suelen ser tomadas como síntoma de deslealtad y no son bien aceptadas.
Puede presentar algunos inconvenientes como:
- Falta de flexibilidad a la hora de adaptarse a necesidades diversas.
- Lentitud de reacción ante los cambios.
- No es un modelo dado a la innovación.
- No saca todo el provecho de los individuos.
Ejemplos prácticos de este tipo de modelo:
- Ejército.
- Sistema burocrático estatal.
- Organización eclesiástica.
Modelo Libre: Puede considerarse el opuesto al jerárquico ya que donde aquél aplica el control y la subordinación de los niveles con sus superiores éste apuesta por la libertad de toma de decisiones de los miembros del grupo.
Sus características principales son:
- Los miembros que forman esta estructura tienen autonomía para la toma de decisiones.
- Se basa en la iniciativa independiente de los individuos.
- Busca promover el cambio y la innovación a través de la creatividad.
Promueve los siguientes valores:
- Creatividad, la libertad del individuo para crear es más importante que la estructura que rige el grupo.
Este modelo puede presentar inconvenientes como:
- Impredecibilidad e inestabilidad, no es posible prever la consecución de objetivos o establecer un plazo exacto para ello.
- Gestión poco eficiente de los recursos.
- Dependencia de una organización de mayor envergadura que las albergue. Debido a lo incierto de sus resultados es complicado que una estructura así pueda ser independiente de otra de mayor estabilidad.
Algunos ejemplos de este tipo de organización pueden ser:
- Grupos universitarios.
- Grupos de creativos de publicidad.
- Grupos de guionistas de TV.
Modelo Adaptativo: promueve también la independencia individual pero basándose en la colaboración de los miembros a través de la negociación y la discusión.
Se caracteriza por:
- La coordinación de iniciativas individuales, la colaboración se basa en la discusión y la negociación.
- Promover distintos puntos de vista.
- La información fluye con facilidad entre los miembros.
- Inclusión de las contribuciones de todos los miembros con lo que éstos se sienten incentivados al sentir los proyectos como propios.
- Los roles y responsabilidades son flexibles y se adaptan a cada tipo de situación.
- Búsqueda del consenso en la toma de decisiones.
- Se obtienen notables resultados en la resolución de problemas complejos.
Promueve valores de:
- Colaboración entre los miembros.
- Igualdad entre miembros.
- Diálogo y consenso.
- Implicación en un objetivo común y propio de todos los miembros del equipo.
Puede presentar inconvenientes como:
- Caer en debates estériles y perder el foco del problema y con ello la perspectiva del objetivo final.
- Ante este tipo de situaciones recurrir de manera sistemática a la toma de decisiones por votación y sin buscar el consenso, lo cual lleva a la segregación de minorías que pierden el sentir el proyecto como propio, resintiéndose con ello la calidad final del producto.
Ejemplos prácticos de este modelo pueden ser:
- Juntas vecinales.
- Comisiones directivas de clubes.
Modelo Sincrónico: Puede considerarse opuesto al adaptativo en el sentido en el que no se considera la discusión o el diálogo como una opción de funcionamiento sistemático ya que todos los miembros del modelo sincrónico presentan una cultura común, algo que los une y los alinea en la voluntad de conseguir un objetivo compartido.
Este modelo se caracteriza por:
- Basarse en un acuerdo tácito de sus miembros.
- Una coordinación basada en un espíritu común sobreentendido resultado de una convivencia armónica durante años o por la huella que dejó en el grupo una fuerte personalidad.
- Existe un entendimiento común de la tarea que se lleva a cabo.
- Entre un miembro emisor y otro receptor puede establecerse una comunicación prediciendo el mensaje aunque no exista un canal de conexión entre ambos.
- Es sumamente eficiente llevando a cabo procedimientos preestablecidos.
Su principal inconveniente es:
- No es adecuado para responder a requerimientos cambiantes.
Como ejemplos prácticos podemos encontrar:
- Ciertos grupos familiares.
- Comunidades monacales.
En el desarrollo tecnológico la consecución de objetivos requiere una parte importante de trabajo rutinario o programable combinado con la necesidad de aportar innovación para la resolución de problemas. Por todo ello, de los modelos de organización expuestos, el que más se aproxima a las características requeridas por el desarrollo de software sería el Adaptativo aunque precisamente su principal inconveniente, el ser un modelo dado a la pérdida de enfoque del objetivo y al estancamiento en problemas menores, es un rasgo común en el desarrollo tecnológico.
Por tanto para el desarrollo de software la solución será la flexibilidad de equipos basados en la combinación de los diferentes modelos clásicos, dando como resultado un Modelo de Estructura Abierta. En él se aplicarán técnicas de cada uno de los modelos para conseguir adaptarse a las características requeridas. Del modelo adaptativo se tomará la base general, manteniendo un trabajo individual pero coordinado mediante la comunicación abierta, la negociación y la discusión; del modelo jerárquico se adoptará el control mediante procedimientos de trabajo programados y finalmente y de manera puntual se contemplarán incursiones en el modelo libre como respuesta a necesidades que requieran de un alto grado de creación e innovación para ser satisfechas. En este Modelo Abierto se promoverán las sesiones presenciales de resolución de problemas así como una asignación de roles no necesariamente fija pudiendo éstos ir rotando entre los miembros del equipo o modificándose según nuevas necesidades.
3. FORMACIÓN DE EQUIPOS DE TRABAJO
Un Equipo de Trabajo es un conjunto de personas reunidas por la autoridad formal de una organización para transformar recursos iniciales en bienes y servicios. Como se decía en la introducción, en el desarrollo de software, como en cualquier otra labor compleja, un equipo de trabajo puede alcanzar objetivos que una sola persona individualmente no podría. Al mismo tiempo el trabajo en grupo implica una planificación y una coordinación de trabajos de las cuales dependerá el resultado final tanto como de la calidad del trabajo de cada uno de los miembros del equipo.
Así pues para la formación del equipo de trabajo deberá contemplarse una primera fase de selección de los miembros, que se llevará a cabo según los criterios que se consideren oportunos, y una segunda de creación del equipo en sí mismo.
Creación del Equipo: Una vez seleccionadas las personas que formarán el equipo debe dedicarse especial atención a la formación inicial del mismo: hay que conseguir convertir a los individuos escogidos en un grupo capaz de trabajar conjuntamente. Para ello se deben sentar las bases de funcionamiento del equipo, se debe transmitir a los miembros un enfoque claro de objetivos y un esquema con la asignación de roles de cada uno, sus respectivas responsabilidades y cuáles serán los principios de interacción entre ellos. Según el tipo de equipo y la envergadura del proyecto para esta primera definición de las claves de funcionamiento podrá recurrirse desde una charla informal o una reunión hasta una convención o retiro de unos días.
La construcción del equipo deberá realizarse teniendo en cuenta la cultura del grupo y el tipo de estructura de organización que se quiere obtener. Así pues para un equipo con estructura jerárquica se deben establecer líneas claras de autoridad, objetivos bien delimitados, una clara asignación de tareas y la búsqueda de directivas simples y concretas. Para uno de estructura libre se buscará definir más una orientación del trabajo que unas reglas, permitiendo flexibilidad en la conformación del equipo así como una asignación natural de roles y haciendo énfasis en la acción individual como forma de contribuir al grupo. En un equipo de estructura adaptativa se buscará incentivar la comunicación fluida dentro del equipo así como fomentar la participación de todos los miembros en la mayor cantidad de aspectos posibles, tratando de implicar a las distintas partes en un objetivo común. Si el equipo fuese de estructura sincrónica deberá buscarse un alto grado de compromiso e identificación de una cultura común y se le dará más importancia al aprendizaje y asimilación de una serie de procesos coordinados que a un sistema de comunicación fluida.
Liderazgo o Management: Como norma general la tarea básica del manager será la de fijar objetivos y criterios claros, transmitirlos con entusiasmo y reforzar el grupo en las facetas menos fuertes de éste. Pero de la misma forma que para la formación del equipo, el tipo de estructura determinará en mayor o menor medida el perfil del manager o líder. Así en un modelo jerárquico se requerirá un líder decidido, que transmita autoridad y directrices claras pero que tenga la capacidad de escuchar a sus subordinados. En un modelo libre se buscará un líder que oriente y enfoque los trabajos sin necesidad de dar órdenes y que mantenga la libertad y la independencia del grupo de cara a la organización mayor al que éste pertenece. En el modelo adaptativo debería priorizarse un líder que se encargara de mantener el objetivo focalizado y que fuera un buen moderador para encauzar las discusiones internas al mismo tiempo que transmite confianza al grupo. En el modelo sincrónico es donde el líder tal vez requiera de unas características más marcadas y más ligadas a la personalidad ya que debe jugar un papel visionario con el cual se identifiquen los miembros del equipo, actuando a la vez como unión entre ellos para evitar el aislamiento y siendo capaz de identificar las necesidades realimentando al grupo con los mensajes apropiados. Además de todo esto en un grupo de modelo abierto el manager deberá actuar como cabeza visible en un equipo de miembros sin jerarquía fija y será completamente responsable de cara al exterior. Para evitar caer en debates improductivos deberá tener la última palabra en la toma de decisiones.
Trabajo en Equipo: En el trabajo en equipo un factor importante es el de la experiencia. Los equipos más eficaces se van formando con el tiempo, un grupo que lleva trabajando un periodo de tiempo será significativamente más eficaz que uno recién formado debido a que ya se ha asimilado un mecanismo de trabajo común y se evitan fallos de descoordinación tan habituales en el comienzo de cualquier labor compartida. Para que un equipo de trabajo adquiera esa experiencia será necesario tener en cuenta varios factores:
- Resolución de conflictos: es común que en todo equipo surjan problemas entre los miembros debido a desacuerdos. Será importante solucionar estas desavenencias de la manera más armonizada posible y en caso de que no se resuelvan deberá entrar en juego la intervención de un superior (el manager) y contemplar, como último recurso, la salida de miembros del equipo.
- Tratamiento de la presión: otro de los grandes problemas que aparecen durante el trabajo en equipo es la incapacidad de soportar la presión ejercida por exigencias de las capacidades personales muchas veces relacionadas con el cumplimiento de plazos. El exceso de presión es un claro inconveniente a la hora de conseguir realizar un trabajo de manera eficaz por lo que es importante trazar inicialmente un plan en el que se establezcan plazos realistas y que permita a los miembros del equipo tener una visión global de la evolución y del ritmo de los trabajos.
- Búsqueda del consenso: en el trabajo en equipo el consenso es la mejor manera para tomar decisiones. La decisión por mayoría como sistema lleva a resultados mediocres. El objetivo será encontrar una respuesta razonable que todos los miembros apoyen o acepten evitando que haya miembros que muestren una oposición frontal a la decisión tomada. La votación por mayoría segrega minorías que pierden apego por el proyecto, lo cual repercute negativamente en el resultado final. Para poder recurrir al consenso como sistema de toma de decisiones debe tenerse en cuenta que requiere tiempo, participación activa, habilidades de comunicación y mentes abiertas.
- Tamaño del equipo: un equipo puede estar formado por un número diverso de miembros pero siempre lo más recomendable será buscar equipos relativamente pequeños, aunque sin sobrecargar de trabajo a sus miembros, que permitan una relación firme entre sus integrantes. Dicho esto el tamaño de un equipo siempre irá inevitablemente unido a la envergadura del proyecto a realizar pero un equipo numeroso siempre será más difícil de coordinar y de conseguir que funcione de manera armónica.
- Propiedades de un equipo eficaz: además de todo lo anterior para conseguir que un equipo funcione de manera eficaz se requerirá que exista una cohesión entre los miembros, una unión fuerte entre ellos en la que destaque el respeto, la tolerancia y la colaboración; unas metas que motiven a los integrantes del grupo, que sean claras y específicas y que se perciban como alcanzables; también es importante realizar un seguimiento de los resultados que se van obteniendo y ver el progreso hacia las metas propuestas.
Motivación como sistema de productividad: a la hora de asegurar la productividad en un entorno de trabajo el factor motivacional suele dar mejores resultados que el impositivo. La creatividad y la productividad son factores que van ligados a la motivación así como a la confianza y a un nivel de presión bien mesurada. Las imposiciones suelen ser entendidas como demostraciones de falta de confianza lo cual implica desmotivación. En el desarrollo de software los profesionales requieren un alto grado de pericia, creatividad y concentración y para ello en muy necesario sentirse motivado. Así pues deberán tenerse en cuenta factores que están directamente relacionados con la mejora de la motivación como son:
- Interés por el proyecto: del que ya se ha hablado anteriormente, sentir el proyecto como propio.
- La formación y el conocimiento recibido: sentirse capacitado para realizar la tarea encomendada.
- Ambiente de trabajo: tratado en el apartado anterior.
- Salario percibido: aunque es complicado hay que tratar de ser justos y evidenciar las injusticias en este aspecto.
- Responsabilidad y confianza recibida: Dar responsabilidad a alguien denota confianza y por lo tanto es una compensación y una muestra de recompensa por un trabajo previo bien hecho.
- Flexibilidad horaria: en la construcción de software el número de decisiones por unidad de tiempo es elevado y para tomar esas decisiones de manera eficiente debe tenerse un nivel de concentración para lo cual aunque se tenga un horario base sí es importante flexibilizar su cumplimiento.
- Evolución profesional: es importante generar perspectivas de crecimiento profesional, mantener cierto grado de ilusión por una progresión.
Resumiendo todo lo expuesto en este punto se podría decir que el trabajo en equipo se resume en la regla de las “cinco C”:
Confianza: La confianza de los miembros del equipo facilita el flujo de información veraz para la optimización de toma de decisiones. Cada persona debe confiar en el buen hacer del resto de sus compañeros. Esta confianza además le llevará a anteponer el éxito del equipo frente al propio lucimiento personal.
Complementariedad: Cada miembro o grupo de miembros del equipo domina una faceta del trabajo y cada uno de estos conocimientos son básicos para la consecución de los objetivos.
Coordinación: El trabajo en equipo implica un grupo de personas trabajando de manera coordinada. El grupo debe trabajar, con un manager o líder a la cabeza, de forma organizada.
Comunicación: El trabajo en equipo exige una comunicación abierta entre sus miembros, esencial para poder coordinar las distintas actuaciones individuales.
Compromiso: Cada miembro se compromete a poner todos sus conocimientos y empeño en sacar el trabajo adelante. Cada componente del equipo es responsable de un cometido y sólo solo si todos cumplen su función será posible la consecución de los objetivos marcados.
4. ETAPAS Y MODELOS DE DESARROLLO DE SOFTWARE
A la hora de conformar un equipo de desarrollo también será necesario tener en cuenta tanto las etapas contempladas en la teoría de la Ingeniería de Software como los diversos modelos de desarrollo para una correcta elección de los miembros, de la organización del grupo y de los plazos y objetivos del proyecto así como de la definición de los roles.
Etapas del desarrollo de software:
- Análisis de requerimientos: el primer paso para crear un producto de software es establecer los requisitos y requerimientos que debe cumplir el mismo. El correcto análisis de requerimientos es básico para conseguir que el programa o la aplicación cumplan con las expectativas del cliente. La dificultad de esta fase reside en saber plasmar y reconocer esos requerimientos a través de las indicaciones facilitadas por el cliente, así como reconocer los no esenciales, completar los que no lo estén o añadir los que serán necesarios de manera indirecta.
- Especificación: una vez se han definido los requerimientos la siguiente fase consistirá en especificar los requisitos del sistema y realizar una clasificación, priorización y una estimación de plazos de ejecución.
- Arquitectura: consistirá en el diseño de los componentes de una aplicación que debe permitir visualizar la interacción entre entidades y permitir su validación. El diseño describirá cómo se construirá la aplicación de software.
- Programación: se trata de convertir el diseño en código de lenguaje de programación. La complejidad y duración de esta etapa estará relacionada con la dificultad del diseño y a los lenguajes de programación que se usen.
- Prueba: consiste en comprobar que el software realiza correctamente las tareas indicadas en la fase de especificación.
- Documentación: engloba todo lo relacionado con la documentación del propio desarrollo del software y de la gestión del proyecto (modelaciones, diagramas, pruebas, manuales de usuario, manuales técnicos) con el objetivo de realizar correcciones en el futuro así como mejorar la usabilidad, realizar el mantenimiento o una futura ampliación del sistema.
- Mantenimiento: fase final dedicada a mantener y mejorar el software corrigiendo los errores que se vayan descubriendo e incorporando nuevos requisitos. Es una fase que puede ocupar más espacio de tiempo incluso que el desarrollo inicial y se estima que más del 60% del tiempo de ciclo de vida de un proyecto se dedica a su mantenimiento.
Modelos de desarrollo:
- En Cascada: ordena rigurosamente las etapas del proceso de desarrollo de manera que el inicio de cada etapa debe estar precedido por la finalización de la anterior. Se estructura en Análisis de Requisitos, Diseño (del sistema y del programa), Codificación, Verificación y Mantenimiento aunque pueden añadirse o eliminarse fases según el tipo de proyecto.
- De Prototipos: consiste en construir un modelo en poco tiempo, usando pocos recursos y centrándose en los aspectos del software que serán visibles para el cliente. Una vez realizado el prototipo se le muestra al cliente que lo evalúa e indica los aspectos a cambiar o mejorar de manera que se va refinando el producto hasta que éste satisface las necesidades del cliente.
- En Espiral: es un modelo en el que se valora el riesgo que aparece a la hora de desarrollar software para lo cual primeramente se estudian las posibles alternativas de desarrollo, se opta por la opción de riesgo más asumible y se hace un ciclo de la espiral. Para las mejoras que el cliente quiera ir incluyendo se repetiría en ciclo evaluando nuevamente el riesgo y las alternativas para elegir la opción más adecuada y realizándose otro ciclo de la espiral. Se repetirán dichos ciclos hasta que el producto satisfaga las exigencias del cliente.
- Por Etapas: parecido al modelo de prototipos ya que se van mostrando al cliente los estados sucesivos del software pero se diferencia de aquel en que las especificaciones no son conocidas al detalle al inicio del proyecto sino que se van desarrollando simultáneamente con las diferentes versiones.
- Iterativo y creciente: se comienza con una implementación simple de los requerimientos del sistema e iterativamente se va mejorando la secuencia evolutiva en las sucesivas versiones hasta que el sistema quede completamente implementado. En cada iteración se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades. Requiere un importante grado de implicación por parte del cliente durante todo el proceso de desarrollo.
- En “V”: representa, en forma de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto, estructurando estas en cuatro niveles, que comienzan en la parte superior con el inicio del proyecto y la fase de especificaciones, continúa con una fase funcional, una fase de diseño y llega al cuarto nivel en la fase de codificación. A partir de ahí se recorre el camino ascendente partiendo de ese cuarto nivel con las fases de test de los niveles antes enumerados hasta finalizar en el nivel 1 con el fin del proyecto. Por su robustez es un modelo de desarrollo especialmente indicado para proyectos de poca envergadura.
- RUP (Rational Unified Process): basado en un proceso cambiante y adaptativo a las necesidades del cliente y para el que es muy importante la interacción con éste. Se basa en la implementación de un ciclo en espiral pero con entrega, aunque solo sea internamente, de etapas iteradas de cara al análisis de la calidad del producto.
5. ROLES DE UN EQUIPO DE TRABAJO DE DESARROLLO DE SOFTWARE
Una vez presentados los esquemas de organización de grupos, los conceptos a tener en cuenta para la formación de equipos de trabajo y las etapas y modelos teóricos en el desarrollo de software finalmente pasamos a enumerar, también de manera teórica, los roles que habitualmente es necesario cubrir para la realización de un proyecto de desarrollo.
Administrador de Proyectos
Será el encargado de controlar y administrar los recursos destinados al proyecto, desde recursos humanos, económicos o tecnológicos hasta otros como el espacio físico, etc. Es una figura que debe existir siempre en todo proyecto de desarrollo aunque no se dedique en exclusiva a un único proyecto o la persona que se encargue de este rol se encargue también de otros simultáneamente. El Administrador de Proyectos debe tener una visión clara y global del proyecto y de sus objetivos. Su misión será conseguir el producto proyectado en el plazo previsto, con el menor gasto posible y cumpliendo siempre con los requisitos de calidad definidos. Se relacionará con todo el equipo de trabajo y su comunicación debe ser fluida con cada uno de los miembros del equipo. Otra de sus responsabilidades de peso será el encargarse de ser la cara visible del proyecto ante los clientes. La persona que se encargue de este rol necesita: tener una visión global del proyecto, para lo cual debe apoyarse en la creación de un organigrama del equipo de trabajo, un modelo de ciclo de vida del proyecto, diagramas de Gantt para la planificación y la estimación de la duración de los trabajos y un contrato con el cliente en el que se plasmen las características y requerimientos del software a construir.
Analista
Es la persona que trabajará con el cliente para realizar el análisis de las necesidades y requisitos a cumplir por parte del sistema que se va a construir. Para el éxito del proyecto es imprescindible que dicho análisis sea acertado, por lo que el Analista deberá mantener una comunicación continua con el cliente ayudando a éste a identificar las necesidades. Se deben conseguir plasmar las características del sistema, separando los requisitos esenciales de los que no lo son o completando características que indirectamente vayan a ser necesarias aunque el cliente en un primer momento no sea consciente de ello. Una vez hayan conseguido enumerarse las necesidades a cubrir el Analista debe realizar la especificación de requisitos que debe satisfacer el software, ya en lenguaje más técnico, de cara al equipo de desarrollo. El éxito del proyecto dependerá también de una buena especificación de requisitos. Por tanto un Analista será una persona que posea capacidades de comunicación, sociabilidad y que consiga entender y hacerse entender por el cliente. Además de conocer las técnicas de diseño y programación que se usarán en fases siguientes debe atesorar un grado importante de creatividad para poder ofrecer alternativas de modelos para la arquitectura del sistema a construir.
Diseñador - Arquitecto
Será el encargado de generar, partiendo de los requisitos establecidos por el analista, el diseño del sistema, tanto a nivel arquitectónico como de detalle. Deberá generar, llegado el caso, prototipos rápidos del sistema para la comprobación del cumplimiento de requisitos y conseguir que el producto final se ajuste al diseño definido pero en general su actividad se centrará en la descomposición de subsistemas para la creación de la arquitectura del sistema, definir la administración de acceso a recursos globales, seleccionar métodos de almacenamiento para las estructuras de datos, elegir el lenguaje o los lenguajes de programación a utilizar, etc. Debe ser un rol asignado a una o dos personas cualificadas y capacitadas para la toma de decisiones y con experiencia previa en la construcción de sistemas, con conocimientos adecuados de programación.
Programadores
La persona/as que deben convertir las especificaciones del sistema en código fuente ejecutable basándose en el lenguaje o lenguajes de programación elegidos por el diseñador y en las herramientas de software de apoyo a la programación. Una de sus misiones consistirá en reducir la complejidad del software a construir para conseguir un producto eficiente y reducir los problemas de testeo, aumentar la productividad reduciendo el tiempo de programación y mejorar las labores de mantenimiento en el futuro. El programador, además de conocer diferentes lenguajes y paradigmas de programación, debe estar familiarizado con las técnicas de diseño utilizadas por el diseñador así como tener experiencia en bases de datos.
Mantenimiento
Una vez validado el programa o la aplicación se entra en la última fase del ciclo de vida del desarrollo y que, como se mencionó en apartados anteriores, puede ser la fase que más se extienda en el tiempo, por lo que económicamente representa una parte importantísima del proyecto. Será un grave error subestimar y más aún ignorar el tiempo que el mantenimiento del software va a requerir. Dentro de las labores de mantenimiento entrarán la adaptación del sistema a cambios, o la realización de mejoras pedidas por los usuarios, o la ampliación de los usos de la aplicación o simplemente la subsanación de errores que vayan detectándose a lo largo del tiempo de uso del programa. Debido a esta importancia como fase en el proceso de desarrollo se ha destacado el Mantenimiento como rol independiente pero por la naturaleza de las tareas a abarcar lo más lógico sería, en proyectos de pequeña o mediana importancia, que de él se encargaran uno o varios de los propios miembros del equipo de desarrollo que ya están familiarizados con el programa creado y que en buena lógica invertirán menos tiempo en el arreglo de fallos o la introducción de cambios que un nuevo técnico que deba estudiar la documentación del proyecto y conocer el sistema para poder realizar los trabajos de mantenimiento.
A parte de todos los roles mencionados existen otro tipo de actividades que podrían dar lugar a nuevos roles pero que se podrían considerar como complementarias a las tareas de los roles ya descritos. El testeo, la comprobación sistemática del correcto funcionamiento en cada una de las fases del producto, será una actividad que se sobrentiende va implícita en cada una de las asignaciones de responsabilidad de los roles así como el control de calidad en las fases o las tareas de documentación de la historia del proyecto. Todas ellas deberían considerarse como una parte más del trabajo de cada uno de los integrantes del equipo, siempre que la entidad del proyecto no exija la dedicación de personas en exclusiva para estas tareas.
Otros expertos consideran necesaria la inclusión de otros roles como el de Comercial que capte clientes y vigile que todo el proceso sea rentable, Programadores específicos para Bases de Datos o Programadores front-end centrados en la usabilidad de las interfaces web, pero en este estudio nos hemos centrado en los que consideramos más básicos y genéricos sin pretender, eso sí, negar la existencia de otras posibilidades que serán totalmente válidas.
6. CONCLUSIÓN
Una vez realizado el recorrido por los modelos de organización de equipos de trabajo, de haber establecido unas recomendaciones para su conformación, de haber hecho un repaso de los modelos y las etapas de desarrollo de software y de haber enumerado unos roles básicos que deben ser considerados en todo equipo de desarrollo conviene destacar que para la creación de software debe tratar de potenciarse la flexibilidad por encima de la rigidez de un modelo u otro. Como casi la mayoría de actividades relacionadas de alguna forma con la innovación y la tecnología, en la creación de software se ha de hacer frente a problemas o necesidades dispares, que distan de poder estar normalizadas o estandarizadas, por lo que no puede hablarse de un modelo único para la creación de equipos de trabajo. Debe tratarse siempre de buscar esa flexibilidad que permita adaptarse y presentar siempre la mejor solución a los problemas que se plantean. Pretender ceñirse sistemáticamente a un mismo modelo para cualquier situación puede suponer a menudo la no consecución de los objetivos por una falta de adaptación a las necesidades reales de cada proyecto. Tener en cuenta las bases teóricas como punto de partida para el planteamiento de modos o formas de trabajo puede ser muy beneficioso para partir en la dirección correcta pero debe realizarse siempre un análisis crítico de cada una de las situaciones y no presentar reticencias ante los cambios o las evoluciones de cara a afrontar cada proyecto.
7. REFERENCIAS
[1] Organización de Equipos de Trabajo de Investigación y Desarrollo; Alejandro Clausse, Facultad de Ciencias Exactas de la Universidad Nacional del Centro, Argentina.
[2] Organización como Empresa, Ministerio de Educación, Bolivia, 2002.
[3] Apuntes de Taller de Ingeniería de Software, Capítulo 4: Roles en el desarrollo de software; David Fuller Padilla, 2003.
[4] Análisis y Gestión del Desarrollo de Software, Trabajo en Equipo y sus Técnicas; David Rodríguez Hernández.
[5] Equipos de Trabajo Efectivos; Mario Morales V., 1995.
[6] Entrada “Metodología de desarrollo de software” del Blog de Jose A. Rodríguez, Septiembre 2008: http://www.iiia.csic.es/udt/es/blog/jrodriguez/2008/metodologia-desarrollo-sotware-modelo-en-v-o-cuatro-niveles
[7] Entrada “Motivación o Imposición” del Blog de Miguel Sierra, Febrero 2010: http://geeks.ms/blogs/msierra/archive/2010/02/08/191-motivaci-243-n-o-imposici-243-n.aspx
[8] Ingeniería del Software, Artículo Wikipedia:
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
