ROLES Y

RESPONSABILIDADE
S DE UN EQUIPO DE
DESARROLLO DE
SOFTWARE

INTRODUCCION
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. En este captulo 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 y por
ltimo, 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.

Administrador de
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.
Por ello debe estar en el control y coordinacin de los diferentes
eventos y actividades de un proyecto.
los recursos asignados pueden ser recursos humanos, econmicos,
tecnolgicos, etc.

OBJETIVOS

Tener el producto a tiempo bajo presupuesto y con los requisitos

de calidad definidos.

Terminar el proyecto con los recursos asignados.

Coordinar los esfuerzos generales del proyecto.

Cumplir con xito las diferentes fases de un proyecto.

Cumplir con las expectativas del cliente.

Relacin con otros roles

Una carta de organizacin de todo el proyecto.

Un plan de trabajo general.

Estimaciones de horas-hombre de cada actividad

*Analistas

*Diseadores

*Testers

*Aseguradores de calidad

*Ing. manutencin

*Documentadores

*Clientes

Plan de trabajo

Definir y establecer estndares a seguir por el grupo.

Definir una estructura organizacional y hacer un diagrama

organizacional.

Capacitar al grupo en las metodologas y estndares a utilizar.

Crear un modelo de ciclo de vida para el proyecto.

Definir un plan y protocolo para desarrollo de reuniones.

Definir una agenda de reuniones con cada rol.

Construir un plan de trabajo especfico que contenga diagramas Gantt

y de flujo de actividades.

Analista

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.

Relacin con otros roles

Administrador de proyecto: El analista debe interactuar con el administrador
de proyecto para estudiar la viabilidad del sistema a desarrollar. Esto es, verificar
la realizacin del sistema con los recursos disponibles. El administrador
de proyecto le asignar a los analistas, la agenda con actividades a ser realizadas
y sus fechas.

Diseador: Los diseadores deben interactuar con

los analistas para determinar la factibilidad del proyecto,
y establecer los objetivos del sistema para un buen diseo.
Los analistas deben permanecer en contacto estrecho
con los diseadores debido a que utilizarn la arquitectura
del sistema.

Relacin con otros roles

Programador: Los analistas son apoyados por los programadores en el entendimiento y
especificacin de los requisitos de usuario y de software. Adems, los apoyan en la construccin de
prototipos rpidos.

Tster: Los analistas participan junto con los tsters en la revisin de los documentos de anlisis
de requisitos.

Asegurador de calidad: Debe revisar los documentos hechos por los analistas.

Administrador de la configuracin: Debe pedir los cambios pertinentes, evitando errores a futuro.

Documentador: Los analistas debern entregarles la informacin que servir para la documentacin
del sistema.

Perfil del analista

Un analista es una persona con capacidades de comunicacin (contacto

estrecho con el cliente ).

Debe ser una persona sociable, expresando sus ideas en forma clara en un
lenguaje comn con el cliente.

Debe ser capas de escuchar y entender al cliente.

Los analistas deben conocer y manejar perfectamente

los mtodos y las tecnologas de apoyo para realizar
las fases de anlisis.

Tambin es importante que los analistas estn

muy familiarizados con las tcnicas de diseo
que se utilizarn en las siguientes fases.

Plan de trabajo

Preparar un documento con preguntas a realizar al

cliente durante las entrevistas.

Determinar las fechas de reunin con el cliente.

Presentacin del documento de especificacin al cliente en

la siguiente reunin.

Generar un documento de especificacin de requisitos de

usuario en base a los acuerdos alcanzados en la primera
reunin.

De ser necesario, realizar las modificaciones al

documento de especificacin
de requisitos de
usuario
y presentarlas al cliente en la prxima
reunin.

Plan de trabajo

Explorar las herramientas CASE a utilizar.

(Rational ROSE, ERwin)

Generar los diagramas de arquitectura.

Revisar los diagramas de arquitectura con

los diseadores.

De ser necesario, realizar las modificaciones

a los diagramas.

Presentar los diagramas de arquitectura finales.

Construir el documento de requisitos de software.

Revisar el documento con los ingenieros

de aseguramiento de la calidad y cliente,
realizando modificaciones
de ser necesario.

Diseadores
Es el encargado de generar el diseo del sistema.
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).

Objetivos
crear una estructura interna limpia y relativamente simple, tambin llamada a veces una
arquitectura. Un diseo es el producto final del proceso de diseo.

Se encuentran construidos en niveles de abstraccin bien definidos, provistos a travs de una

interfaz bien definida y controlada, y construida sobre facilidades igualmente bien definidas y
controladas en niveles de abstraccin inferiores.

Existe una separacin clara de preocupaciones entre la interfaz y la implementacin de cada

nivel, haciendo posible cambiar la implementacin de un nivel sin violar las suposiciones que
hicieron los clientes.

La arquitectura es simple, comportamiento comn se obtiene a travs de abstracciones y

mecanismos comunes

Perfil de un diseador
mostrar

habilidad inusual para sintetizar soluciones

construibles por sobre un gran conjunto de
restricciones

Generalmente

son los ms capacitados para realizar

decisiones estratgicas

Deben
Deben

tener habilidades de programacin adecuadas.

conocer muy bien la metodologa de diseo

utilizada

Plan de trabajo
Organizar
Asignar

el sistema en subsistemas.

los subsistemas a procesos y tareas.

Seleccionar

un administrador de datos.

Identificar

recursos globales y determinar

mecanismos de acceso.

Elegir

un enfoque para implementar el control

de la ejecucin.

Considerar

condiciones de borde

PROGRAMADORES

Los programadores deben convertir la especificacin del sistema

en cdigo fuente(conjunto delneas de texto, instrucciones que
debe seguir lacomputadora) ejecutable utilizando uno o ms
lenguajes de programacin, as como herramientas de software de
apoyo a la programacin.

PROGRAMADORES
OBJETIVOS
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.

PROGRAMADORES
PERFIL DEL PROGRAMADOR
Debe conocer diferentes lenguajes de programacin disponibles para el
ambiente seleccionado, y debe tener experiencia en el lenguaje de
programacin seleccionado. Es preferible que el programador tenga
conocimientos en diferentes paradigmas de programacin y estilos.

Debe adems, conocer perfectamente las tcnicas de diseo

utilizadas por el diseador. Tambin es deseable que el programador
tenga conocimiento en varias metodologas de diseo.
Las bases de datos son una herramienta muy poderosa en un proyecto.
programadores deben tener experiencia en bases de datos.
De ser posible, es preferible que los programadores tengan
experiencia en el tipo de proyecto que se desea realizar.

Los

Tester
El tster es el encargado de asegurar la calidad de cada uno de los productos sujeto que apoye el
proceso de deteccin y eliminacin de los errores y defectos del sistema en construccin,
(documentos, prototipos, etc). 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).

Actividades y metas

Actividades
Metas
Participacin
en
el Prevenir errores en las
proceso de especificacin etapas tempranas del
del sistema
desarrollo
Interaccin
diseador

con

el Realizar tests al diseo,

obteniendo ndices de
medicin

Realizar los tests, apoyado Realizar

diferentes
por los programadores
tests,
obtener
una
buena interpretacin de
ellos, y realizar los
ajustes
Pertinentes
Informar
sobre
los El grupo de desarrollo es
resultados obtenidos
informado
sobre
los
progresos y resultados
obtenidos

Metodologas
Se utilizan dos tcnicas:
Los tests de caja blanca corresponden a un mtodo
de diseo de casos de tests que utilizan
la estructura
de control del diseo procedural para derivar
los casos de
tests. Usando este mtodo, el tster
puede derivar casos de tests para lo siguiente:
Asegurarse que todos las trayectorias independientes en un mdulo han sido visitadas al menos una
vez.
Ejercitar todas las decisiones lgicas en sus lados verdadero y falso.
Ejecutar todos los loops en sus lmites y sobre sus lmites operacionales.
Ejercitar estructuras de datos internas para asegurar su validez.

Metodologas
Los tests de caja negra se focalizan en los requisitos
de usuario del sistema. De esa
forma, este tipo de
tests permite que los tsters generen conjuntos
de datos de entrada que ejercitarn completamente
los requisitos
del sistema. Los tests de caja negra no son una alternativa a los tests de caja blanca. Ms an, corresponde
a un enfoque complementario que posiblemente descubra una clase diferente de errores.
Los tests de caja negra tratan de encontrar errores en las siguientes categoras:
Funciones incorrectas o faltantes.
Errores de interfaces.
Errores en estructuras de datos o acceso a bases de datos externas.
Errores de rendimiento del sistema y errores de inicializacin y terminacin.

Perfil de un tester
Ser un buen programador en el lenguaje seleccionado, y tener experiencia en el
desarrollo de sistemas.
Conocer bien la metodologa de diseo utilizada.
Ser sistemtico en las revisiones de cdigo y resultados de los tests.
Tener una personalidad agresiva para buscar errores en el cdigo y documentos
del proyecto.
Debe adems tener una personalidad alegre, debido a que debe relacionarse con
gran parte de los miembros del equipo de
desarrollo.

Documentador
La documentacin sirve, entre
otras cosas, para conocer la
historia del proyecto. Hay que
destacar que los documentos
no se escriben al final del
proyecto, sino que se van
generando junto con las
diferentes fases del proyecto.

SE CLASIFICAN EN DOS
1.- Documentacin de procesos: Los documentos
pertenecientes a esta categora registran la
informacin del proceso de desarrollo y manutencin
del sistema.

Planificacin

y control de procesos (planes,

calendarios, estimaciones).

Reportes sobre recursos utilizados durante el

desarrollo.

Estndares a ser utilizados en las diferentes fases.

Registro de ideas y estrategias a ser consideradas por

el equipo.

Lgica de las decisiones de diseo

2.- Documentacin de producto

Estos documentos describen el desarrollo del producto
desde los puntos de vista tcnico

Estos 2 Documentacin tienes las siguientes

caractersticas
La documentacin de sistema incluye los documentos desde la
especificacin de requisitos hasta el plan de testeo de aceptacin
final.
Manutencin y debe ser actualizada cada vez que se realizan
cambios al sistema.

Objetivos

Permitir el almacenamiento y recuperacin de la

documentacin de los procesos y productos ms recientes
durante el desarrollo

Mantener la consistencia en la apariencia y estructura de

los documentos.

Asegurarse que los cambios que necesitan hacerse en el

sistema sern reflejados en la documentacin
correspondiente

Elaborar, almacenar y permitir la recuperacin de las

actas y registros generados durante las reuniones

Construir el manual de usuarios del sistema

Perfil del documentador

El documentador debe ser una persona
ordenada, con capacidades de mantener una
gran cantidad de informacin en forma
ordenada y accesible.
El documentador debe poseer capacidades,
deber disear y construir el repositorio creatividad para presentar la informacin y
aptitud

Cliente comprometido
En el desarrollo de software nos interesa tener clientes comprometidos. Es vital para el xito del
proyecto. Un cliente comprometido es aquel que participa en todas las etapas del proyecto,
compartiendo deberes y responsabilidades.

Entre sus tareas estn:

Liderar el proyecto de software cuando la organizacin lo requiere.
Definir los objetivos del proyecto negociando con sus clientes las caractersticas que le afecten.
Revisar y aprobar documentos en forma responsable.
Entregar los recursos necesarios para la realizacin del proyecto.
Escribir o participar en la elaboracin del manual de usuario del sistema (MUS).
Realizar la capacitacin del sistema a sus usuarios.
Construir el plan de pruebas de aceptacin del sistema y aplicarlo al final del proyecto,
aceptando o rechazando la entrega.

Relaciones con otros roles

Administrador de proyecto. El cliente comprometido llevar toda la relacin formal del proyecto a travs de
su administrador.
Analista. El cliente comprometido participar en reuniones sistemticas de anlisis, dirigidas por los analistas.
Diseador: El cliente comprometido debe participar en las fases de revisin
DA/R y DD/R junto a los diseadores.
Programador. El cliente comprometido debe

participar en la fase de revisin

DD/R junto a los programadores.

Tster. El cliente debe preparar el plan de aceptacin
apoyo del tster.

parcial y plan de aceptacin definitiva, con

Asegurador de calidad. El cliente comprometido debe apoyar

al asegurador de calidad en su bsqueda
de diferencias entre los
requisitos de usuario y las funcionalidades implementadas en el
sistema.