ROLES EN EL DESARROLLO DE SOFTWARE

El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo.
Adems, esta actividad requiere de distintas capacidades, las que no se encuentran todas en una
sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que cubran
todas las capacidades requeridas. Cada una de esas personas aportar al grupo parte del total de
las capacidades necesarias para llevar a cabo con xito el desarrollo. Por ello, es que cada persona
debe tener un rol dentro del grupo, que viene dado por su experiencia y capacidades personales. A
continuacin se describen los roles que tradicionalmente se consideran en el desarrollo de software.
Estos roles son:

Administrador de proyecto,
Analista,
Diseador,
Programador,
Tster,
Asegurador de calidad,
Documentador,
Ingeniero de manutencin,
Ingeniero de validacin y verificacin,
Administrador de la configuracin
El cliente.

Para cada uno de estos roles, se definen sus objetivos, actividades, interaccin con otros roles,
herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo. Hay que sealar que es
posible que no se requieran todos los roles en un desarrollo. Eso depender del tamao y del tipo
del desarrollo.
El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus responsabilidades y
actividades asociadas, hace que se produzcan problemas. Por un lado, es posible que una o ms
actividades no estn asociadas a ningn rol, con lo que el proyecto sufrir. Por otro lado, es posible
que una o ms actividades estn asociadas a ms de un rol. Esto producir problemas entre los
miembros afectados, lo que tambin redunda en problemas en el desarrollo del sistema. Por lo
anterior, se hace necesario que cada miembro conozca muy bien su rol dentro del proyecto, as
como las responsabilidades y actividades asignadas.

LA FBULA DE LA GRANJA
Un da cualquiera, los animales de una granja decidieron hacer una fiesta, con el propsito de pasar
un momento agradable. Para organizar la fiesta, se reunieron el mismo da en la maana. Cada
animal deba llevar algo a la fiesta. Como es lgico, a la vaca le pidieron la leche. A la gallina, le toc
llevar los huevos. Y al cerdo, el tocino.
En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el cerdo se encuentra
involucrado. Su participacin le obliga a entregar parte de si mismo como aporte para la fiesta. Al
cerdo le toca aportar una cuota de sacrificio mayor. Lo anterior muestra la diferencia entre participar
en un evento y estar involucrado.
Tomemos esta fbula para caracterizar a los miembros del grupo de un desarrollo de software.

Cmo se comportan, en general? Participan o estn comprometidos en el proceso de desarrollo

de software? Parece claro que lo deseable, desde el punto de vista del problema completo, es tener
integrantes comprometidos. Pero, Cmo se obtienen estos miembros comprometidos? Es posible
crear miembros del grupo comprometidos? Administrador de proyecto comprometido, analista
comprometido, diseador comprometido, programador comprometido, tster comprometido,
asegurador de calidad comprometido, documentador comprometido, ingeniero de manutencin
comprometido, ingeniero de validacin y verificacin comprometido, administrador de la
configuracin comprometido y cliente comprometido?
La fbula anterior nos ensea la diferencia entre participar y estar comprometidos en una actividad.
Es claro que para tener miembros del equipo de desarrollo comprometido, es necesario capacitarlos
en sus deberes y derechos en el ciclo de vida del desarrollo de software.
Es muy poco probable que un miembro no capacitado pueda estar comprometido con los objetivos
del proyecto. Este presentar claras deficiencias en el momento de participar en el proceso. Como
ejemplo, se mencionan algunas:
1. Un miembro no capacitado no entender el lenguaje tcnico utilizado por el resto de los
miembros. Muchas veces, entender una cosa diferente a la expresada por sus pares. Esto es
comn debido a diferencias en el lenguaje.
2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se
presentan durante el desarrollo. Sera muy bueno que el miembro pudiera aportar sus conocimientos
en su dominio del problema durante todo el ciclo de desarrollo del proyecto. Saber cuando exigir y
cuando ceder. Conocer los estndares de desarrollo, de documentacin, de aseguramiento de la
calidad.
3. Un miembro no capacitado no presupuesta su involucracin en el proyecto, slo su participacin.
Este solo hecho reduce las posibilidades de xito del proyecto. Tambin aumenta los tiempos de
desarrollo, disminuye la calidad del sistema, aumentan los riesgos de rechazo del sistema por parte
de la comunidad de clientes, entre otros.
Lo anterior sugiere que es necesario contar con Miembros comprometidos para desarrollar
correctamente el proyecto. Aspectos a considerar son los de crear un lenguaje comn entre el
equipo de desarrollo, as como hacer que entiendan claramente sus deberes y obligaciones.
Por otro lado, los clientes tambin deben estar comprometidos con el desarrollo. Eso significa que
deben conocer el ciclo de vida escogido, cual es su participacin en cada una de las fases del ciclo,
y la cantidad de esfuerzo y recursos que se espera que pongan en cada momento del proyecto. Es
de vital importancia que participen activamente en la etapa de anlisis, as como en todas aquellas
actividades de revisin y aceptacin.
En caso que el cliente no tenga dicha experiencia, se hace necesario que antes de un desarrollo, se
los capacite para convertirlos en clientes comprometidos. Lo anterior requiere de trabajo, pero va por
el camino correcto del xito de un proyecto de software.
Es claro entonces que todos los integrantes del equipo de desarrollo debiesen estar comprometidos
con el proyecto, incluyendo los clientes. Lo anterior implica trabajar con el equipo completo en torno
a las metas a lograr, as como las cualidades y caractersticas deseables de cada uno de ellos. Para
ello, se requiere entender correctamente las caractersticas de liderazgo dentro de un grupo
humano.
1. Administrador o Gerente del proyecto
El administrador o Gerente del proyecto es la persona que administra y controla los recursos
asignados a un proyecto, con el propsito de que se cumplan correctamente los planes definidos.
Los recursos asignados pueden ser recursos humanos, econmicos, tecnolgicos, espacio fsico,

entre otros. En un proyecto, siempre debe existir un administrador. No obstante, un administrador

puede dirigir ms de un proyecto.
El administrador o gerente no es dueo de nada, es slo un administrador temporal de los recursos.
Como no es dueo de nada, debe dejarlos en la misma o mejor condicin de como los recibi. Por
ello, el foco de una buena administracin debe estar en el control y coordinacin de los diferentes
eventos y actividades de un proyecto. Adicionalmente, deben crearse las mejores condiciones
posibles para que se realicen las 11 actividades. Una de las preocupaciones principales para los
administradores o gerentes, debe ser el tener una visin y misin claras del proyecto, trabajando
para que ambas se cumplan.
El rol de administrador de proyecto es un rol muy importante, debido a que sus acciones y
decisiones afectan al proyecto completo.
Relacin con otros roles
El administrador de proyecto debe relacionarse con todo el equipo de trabajo. Para ello, debe darle
apoyo con lo siguiente:
- Una carta de organizacin de todo el proyecto.
- Un plan de trabajo general.
- Estimaciones de horas-hombre de cada actividad.
El administrador deber tener una comunicacin fluida con cada miembro del equipo para analizar
problemas particulares, y si es necesario, tomar acciones correctivas.
Analistas
La palabra Anlisis se refiere a una caracterstica tpicamente relacionada con la inteligencia
humana.
Esta se refiere a la habilidad de poder estudiar un problema de una complejidad determinada,
descomponiendo el problema en subproblemas de menor complejidad. De esa forma, la solucin del
problema completo se obtiene como la suma de las soluciones de los subproblemas de menor
complejidad.
Lo anterior indica que la fase de anlisis en un proyecto de construccin de software se refiere a la
especificacin de un problema como la suma de subproblemas de menor complejidad. Como el
experto en el problema es el cliente, se hace necesario trabajar junto a l para realizar la
especificacin correctamente.
Los miembros del grupo que trabajan con el cliente para realizar el anlisis y especificacin del
sistema a construir, son precisamente los analistas.
Para que el trabajo de los analistas tenga sentido para todos los integrantes del grupo, se hace
necesario ponerse de acuerdo en la forma como se realizar la especificacin, as como la forma
como el resto del grupo la entender. Esto sugiere el uso de un estndar para realizar la fase de
anlisis del problema. En el caso del estndar de la ESA, el anlisis se divide en dos fases:
especificacin de requisitos de usuario y especificacin de requisitos de software. Los analistas
deben liderar ambas fases.
Una de las razones ms frecuentes del fracaso de un desarrollo de software es la de realizar un
anlisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y especificar el sistema que
desea el cliente, los desarrolladores construyen sistemas que no cuentan con las caractersticas que
el cliente desea. Ese error se repite una y otra vez, y se debe bsicamente a la inexperiencia del
grupo de desarrolladores.
Diseadores

Es el encargado de generar el diseo del sistema. Entre sus funciones est:

- Generar el diseo arquitectnico y diseo detallado del sistema, basndose en los requisitos.
- Generar prototipos rpidos del sistema (con analistas y programadores) para chequear los
requisitos.
- Generar el documento de diseo arquitectnico de software (DDA), y mantenerlo actualizado
durante el proyecto.
- Velar porque el producto final se ajuste al diseo realizado (funciones de tster).
En cada disciplina de la ingeniera, el diseo acompaa el enfoque disciplinado que se utiliza para
inventar la solucin de un problema, entregando as un camino entre los requisitos y la
implementacin.
En ingeniera de software, el propsito del diseo es la construccin de un sistema que cumpla con
los siguientes aspectos:
- Satisfaga una especificacin funcional dada.
- Cumpla con las limitaciones del medio receptor del sistema.
- Cumpla requisitos implcitos y explcitos de rendimiento y uso de recursos.
- Satisfaga criterios de diseo implcitos y explcitos en la forma del artefacto construido.
- Satisfaga restricciones del mismo proceso de diseo, tal como su duracin y costo, o las
herramientas disponibles para realizar el diseo.
El propsito del diseo es el de crear una estructura interna limpia y relativamente simple, tambin
llamada a veces una arquitectura. Un diseo es el producto final del proceso de diseo. As, una de
las metas en el diseo de software es derivar una arquitectura del sistema. Esta arquitectura sirve
como un marco desde el cual se conducen ms actividades de diseo detallado.
Programadores
Los programadores deben convertir la especificacin del sistema en cdigo fuente ejecutable
utilizando uno o ms lenguajes de programacin, as como herramientas de software de apoyo a la
programacin.
El xito del desarrollo de software depende grandemente de conocimiento. Este conocimiento no
slo corresponde a habilidades de programacin y de administracin de proyectos, sino que a una
percepcin y entendimiento de los ltimos desarrollos de la industria del software. En los mercados
actuales, rpidamente cambiantes y altamente competitivos, se hace necesario conocer los ltimos
desarrollos, quien da soporte, y como pueden beneficiar al proyecto y a la organizacin. A travs de
este conocimiento es que la organizacin genera un camino hacia el xito futuro.
Uno de los principales objetivos de los programadores durante su trabajo debe ser la de reducir la
complejidad del software. Algunos de los beneficios que implican la reduccin de la complejidad del
programa son:
- Menor cantidad de problemas de testeo.
- Aumento de la productividad de los programadores.
- Aumento de la eficiencia en la manutencin del programa.
- Aumento de la eficiencia en la modificacin del programa
El lenguaje de programacin escogido afecta significativamente los costos, confiabilidad y
rendimiento del sistema. Ningn lenguaje es ideal para todas las aplicaciones. La eleccin del
lenguaje debe estar basada en la naturaleza de las aplicaciones (tiempo-real, incrustada,
procesamiento batch, basado en Web, entre otros) y en la importancia de algunos indicadores de

calidad (rendimiento versus confiabilidad). La base de datos tambin debe ser confiable y proteger
privacidad e informacin comercial de usuarios no autorizados.
Los estilos de codificacin incluyen los nombres de variables, la forma de hacer comentarios en el
cdigo fuente, el diseo y escritura de rutinas y mdulos, la creacin de tipos de datos, la seleccin y
control de estructuras y la organizacin de bloques de instrucciones. A veces, algunos de estos
factores son determinados por la sintaxis y el paradigma de programacin utilizados, existiendo
estndares para lo anterior. Tpicamente, un grupo de programadores, o una empresa, utiliza el
mismo estndar con el propsito de que todos los programadores puedan acceder fcilmente a todo
el cdigo.
Las modificaciones hechas al cdigo deben ser solicitadas por el administrador de configuracin.
Otras veces, las modificaciones son solicitadas por el ingeniero de testeo directamente al
programador. En algunos casos, algunas modificaciones no requieren que se completen los
formularios de cambio debido a que los cambios solicitados no son relevantes o no requieren
aprobacin del comit de cambios (por ejemplo, no modifican los requisitos de usuarios). Es
importante destacar que los programadores no deben realizar cambios al software solicitados
directamente por el cliente.
Las reuniones realizadas entre programadores son muy importantes. En ellas se mantiene al da al
equipo sobre el estatus de la codificacin, los problemas que tienen las otras personas, la forma en
que otras personas abordaron una tarea especfica, nuevas necesidades internas y cambios al
cdigo, y hacer revisiones al cdigo de otros programadores.
Tster
El desarrollo de un sistema de software requiere la realizacin de una serie de actividades de
produccin.
En dichas actividades existe la posibilidad de que aparezcan errores humanos. Dichos errores
pueden empezar a aparecer desde el primer momento del proceso. Por ejemplo, los requisitos del
sistema pueden ser especificados en forma errnea o imperfecta. Por ello, el desarrollo de software
considera una actividad que apoye el proceso de deteccin y eliminacin de los errores y defectos
del sistema en construccin.
El objetivo del rol de tster es precisamente realizar dichas tareas.
El tster es el encargado de asegurar la calidad de cada uno de los productos (documentos,
prototipos, entre otros). Entre sus tareas estn:
- Construir y aplicar los planes de prueba unitarios, de mdulo, de sistema, y aceptacin parcial,
mantenindolos actualizados durante el proyecto.
- Velar por la completitud, y exactitud (no ambigedades) de todos los documentos del proyecto.
- Coordinar las inspecciones, y/o caminatas.
- Velar por la adhesin al estndar adoptado para el desarrollo.
- Velar por la calidad del producto final (cumplimiento de los requisitos).
Aseguradores de Calidad
En la actualidad, los factores dominantes en la administracin de proyectos de software son los
tiempos y costos de desarrollo. Existen buenas razones para ello. Los tiempos y costos de desarrollo
son con frecuencia, muy grandes. Por ello, la administracin se ha concentrado en tratar de resolver
dichos problemas. Sin embargo, existe un gran peligro en esto. En la medida que crece la presin
por cumplir con las fechas estipuladas, y reducir los costos, es la calidad del producto la que sufre.
Cuando se acelera el desarrollo de un sistema que est atrasado, generalmente se corta todo lo que
no se considere esencial, usualmente cortando las actividades de verificacin y testeo, resultando
en un producto de calidad reducida.

Se hace necesario encontrar una nueva ecuacin para el desarrollo de software. No debe ser
simplemente producto de software = a tiempo + dentro de los costos. Debiese ser producto de
software = calidad + a tiempo + dentro de los costos. Para ello, debe existir el convencimiento
individual y de la gerencia de considerar la calidad como una meta final, junto con el cumplimiento de
plazos y costos. Como se mencion antes, la calidad corresponde a un conjunto de atributos a
cumplir por el desarrollador.
Tpicamente, dichos atributos se encuentran definidos en la forma de un estndar, el que debe
cumplirse.
Administracin de Configuracin
La administracin de la configuracin es una disciplina que tradicionalmente se aplica al desarrollo
de sistemas de hardware, al desarrollo de elementos de hardware o sistemas de hardware/software.
La administracin de la configuracin de software corresponde a la administracin de la
configuracin aplicada a un sistema, o a partes de un sistema, predominantemente correspondiente
a software. Su aplicacin, en conjunto con otras disciplinas, lleva al desarrollo de sistemas en forma
ordenada y estructurada.
La administracin de la configuracin es una disciplina que aplica direccin y vigilancia tcnica y
administrativa a:
- Identificar y documentar las caractersticas funcionales y fsicas de tems de configuracin.
- Auditar los tems de configuracin para verificar cumplimiento de especificaciones, control de
interfaces y documentos, as como otros requisitos adicionales que pueda definir el contrato.
- Controlar cambios a los tems de configuracin y su documentacin relacionada.
- Registrar y reportar informacin necesaria para administrar tems de configuracin en forma
efectiva, incluyendo el estatus de cambios propuestos y el estatus de implementacin de cambios
aprobados.
- Mantener el repositorio del proyecto actualizado con las ltimas versiones de todos los entregables
del proyecto.
- Administrar el software utilizado para el control de versiones.
- Definir y controlar perfiles de acceso a los archivos del proyecto.
- Velar por la completitud y exactitud del repositorio del proyecto.
Los problemas de software ms frustrantes son frecuentemente ocasionados por una pobre
administracin de la configuracin. Los problemas son frustrantes debido a que requieren tiempo
para arreglarlos, y usualmente ocurren en el peor momento, y son totalmente innecesarios.
La administracin de la configuracin ayuda a reducir estos problemas coordinando los productos de
muchas personas que trabajan en un proyecto comn. Sin ese control, su trabajo va a producir
conflictos con frecuencia, resultando en problemas como los descritos a continuacin:
- Modificaciones simultneas _ Cuando dos o ms personas trabajan separadamente en el mismo
programa o documento, el ltimo en realizar los cambios puede fcilmente destruir el trabajo del
otro.
- Cdigo comn _ En grandes sistemas, cuando se modifican funciones comunes de un programa,
es necesario notificarlo a todos los miembros del grupo. Sin una administracin de cdigo efectiva,
no hay forma de estar seguro de encontrar y alertar a cada uno de los miembros del equipo.
- Versiones _ Muchos de los grandes programas son desarrollados en releases evolucionarios. Con
uno siendo utilizado por el usuario, otro en testeo, y un tercer en desarrollo, los arreglos de errores
deben ser propagados entre ellos. En sistemas de gran tamao con varios releases activos en forma