ROLES EN EL DESARROLLO DE SOFTWARE

INTRODUCCIÓN

El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en

grupo. Además, 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
capítulo se describen los roles que tradicionalmente se consideran en el desarrollo de
software. Estos roles son administrador de proyecto, analista, diseñador, programador, téster,
asegurador de calidad, documentador, ingeniero de manutención, ingeniero de validación y
verificación, administrador de la configuración y por último, el cliente. Para cada uno de estos
roles, se definen sus objetivos, actividades, interacción con otros roles, herramientas a
utilizar, perfil de las personas en ese rol y un plan de trabajo.

Hay que señalar que es posible que no se requieran todos los roles en un desarrollo. Eso
dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo de un sistema de
información de gran tamaño requerirá más roles que uno de menor tamaño.

Por otro lado, si el tipo del proyecto está enfocado más hacia la parametrización e integración
de sistemas, requerirá algunos roles en menor medida y otros en mayor. Es posible también
que una persona realice las labores de más de un rol al mismo tiempo. Esto, sobre todo en
proyectos de desarrollo de software más pequeños. No obstante, es imprescindible que
dichas personas conozcan completamente todas sus tareas.

Por otro lado, también es posible la situación de tener más de una persona con un mismo rol
en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad mediana hemos
utilizado con éxito la fórmula de tener un administrador de proyecto, dos analistas, dos
diseñadores, dos programadores y un téster. Eso hace un total de ocho personas en un
grupo. Las actividades de documentación y administración de configuración son asumidas
por todos los roles. Parte de las actividades de aseguramiento de calidad son asumidas por
el téster. El resto de las actividades no son realizadas.

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 más actividades no estén asociadas a ningún rol, con lo que el proyecto
sufrirá. Por otro lado, es posible que una o más actividades estén asociadas a más de un rol.
Esto último producirá problemas entre los miembros afectados, lo que también 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. Eso es lo que se intenta describir en este capítulo.

1
Actividad Integradora Desarrollo e Implementación de Sistemas
ADMINISTRADOR DE PROYECTO

El administrador de proyecto es la persona que administra y controla los recursos asignados

a un proyecto, con el propósito de que se cumplan correctamente los planes definidos. Los
recursos asignados pueden ser recursos humanos, económicos, tecnológicos, espacio físico,
etc. En un proyecto, siempre debe existir un administrador. No obstante, un administrador
puede dirigir más de un proyecto.

El administrador no es dueño de nada, es sólo un administrador temporal de los recursos.

Como no es dueño de nada, debe dejarlos en la misma o mejor condición de cómo los
recibió. Por ello, el foco de una buena administración debe estar en el control y coordinación
de los diferentes eventos y actividades de un proyecto. Adicionalmente, deben crearse las
mejores condiciones posibles para que se realicen las actividades.

Una de las preocupaciones principales para los administradores debe ser el tener una visión
y misión claras del proyecto, trabajando para que ambas se cumplan. En otras palabras, el
foco de un administrador de proyecto debe estar en el bosque más que en los árboles. Sin
embargo, debe cuidar cada árbol ya que cada uno de ellos contribuye al bosque.

El rol de administrador de proyecto es un rol muy importante, debido a que sus acciones y
decisiones afectan al proyecto completo.

Objetivos
Algunos de los objetivos de un Administrador de Proyecto son los siguientes:
1. Tener el producto “a tiempo”, “bajo presupuesto” y con los requisitos de calidad definidos.
2. Terminar el proyecto con los recursos asignados.
3. Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a
cumplir sus objetivos particulares. Al final, se cumplirá el objetivo general.
4. Cumplir con éxito las diferentes fases de un proyecto, utilizando herramientas de
administración.
5. Cumplir con las expectativas del cliente.

Algunos de los objetivos específicos a cumplir por un administrador de proyecto son los
siguientes:
1. Comenzar y terminar cada actividad de acuerdo a lo planificado.
2. Lograr el mejor uso de los recursos disponibles.
3. Observar cada actividad para detectar y resolver inconvenientes.

Actividades y metas
A continuación se muestra el conjunto de actividades a realizar por el administrador de
proyecto para lograr cumplir con éxito las metas definidas.

Actividades Metas
Desarrollo eficiente de reuniones:
2
Actividad Integradora Desarrollo e Implementación de Sistemas
El administrador de proyecto está a cargo de
las reuniones y presentaciones entre el grupo
y con los clientes.
Debe conducir la reunión usando el protocolo
establecido.
Debe cuidar de todos los aspectos de la
reunión (layout de la sala, luces, sillas,
mesas, computadores, proyección y sonido,
Las reuniones logran sus objetivos.
pizarra, lápices, material que se entrega,
etc.). Mida el tiempo y compárelo con lo
Los puntos principales de cada reunión
planificado, para así maximizar la eficiencia.
deben ser documentados en minutas donde
Cada reunión debe ser evaluada. De ser
es documenten los acuerdos y compromisos
necesario, deben tomarse acciones
establecidos.
correctivas.
Promueva reuniones de integración
(desayunos, comidas, coffee breaks, etc.),
donde el grupo pueda intercambiar puntos de
vista y experiencias, creatividad y
espontaneidad.
Desarrollo organizacional:
Conduzca reuniones y seminarios cuando el Asigna las actividades y el proyecto en un
grupo determina los próximos puntos: contexto amplio y con sentido para el grupo
• Visión. de trabajo.
• Misión.
• Metas. Ayude al equipo en su desarrollo
• Objetivos. organizacional.
• Actividades.

Administración:
Entregar un plan de trabajo general basado
en diagramas Gantt y de flujo de actividades,
apoyado con el plan de trabajo de cada rol.
El plan de trabajo general deberá contener
estimaciones de horas-hombre de cada
actividad, que permita estimar los recursos Coordinar todas las actividades.
humanos requeridos.
Desarrollar el contrato junto con el cliente.
Realizar actividades de organización,
dirección y control.
Trabajar con los analistas para estudiar las
necesidades de los clientes y los requisitos
del sistema.
En general:
• Realizar reuniones generales y seminarios

3
Actividad Integradora Desarrollo e Implementación de Sistemas
de evaluación y planificación.
• Realizar reuniones de evaluación con cada
rol.
• Obtener información sobre el estado el
proyecto para el equipo y para el cliente.

Relación 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 organización de todo el proyecto.
• Un plan de trabajo general.
• Estimaciones de horas-hombre de cada actividad.

El administrador deberá tener una comunicación fluida con cada miembro del equipo para
analizar problemas particulares, y si es necesario, tomar acciones correctivas. En particular,
el administrador de proyecto deberá apoyar de la siguiente forma a cada rol:

• Analistas: Trabajar con los analistas para estudiar las necesidades de los clientes y los
requisitos del sistema.

• Diseñadores: Trabajar con ellos para diseñar la arquitectura del sistema de acuerdo con los
recursos asignados al proyecto. El administrador de proyecto requiere la arquitectura del
sistema para determinar el plan de trabajo de los demás roles.

• Tésters: Trabajar con ellos para determinar que tipo de testeo deberá utilizarse, y con que
profundidad, de acuerdo con los requisitos de seguridad en el diseño del sistema y de los
recursos disponibles. Los resultados de los tests ayudan a determinar el éxito del proyecto,
preocupación principal de la administración de proyecto.

• Aseguradores de calidad: La información provista por este rol ayuda a conocer el avance
del proyecto. Este rol observa si cada una de las actividades se realiza de acuerdo a las
especificaciones planificadas.

• Ingenieros de manutención: Generalmente la manutención utiliza una cantidad muy

importante de recursos del proyecto. Por ello, el administrador debe conocer los planes de
manutención, y de ser necesario, ajustarlos a los recursos disponibles.

• Documentadores: El administrador de proyecto tomará como referencia los documentos

controlados por los documentadores para elaborar planes y la evaluación del proyecto.

• Clientes: El administrador de proyecto deberá administrar la relación con los clientes,

desarrollando una comunicación fluida con éstos, y siendo la cara visible del proyecto.

Herramientas de trabajo

4
Actividad Integradora Desarrollo e Implementación de Sistemas
El administrador de proyecto deberá utilizar herramientas que apoyen su trabajo. Algunas de
estas herramientas se describen a continuación:

• Herramientas de comunicación, tales como teléfono fijo y móvil, que permita ser localizado
y localizar rápidamente a otros miembros del equipo. El correo electrónico y grupos de
discusión también son herramientas de uso frecuente.
• Herramientas de administración de proyectos, que permitan definir y modificar diagramas
Gantt y de flujo de actividades. Ejemplos de esto son MS Project 2000 y MS Project Central,
y Primavera.
• Herramientas que permitan contabilizar el uso de recursos, tal como una planilla de
cálculos. Ejemplo de esto es MS Excel.
• Herramientas de presentación, tal como MS Power Point.
• Procesador de texto, tal como MS Word.
• Grabadora de audio.
• Grabadora de video.

ANALISTAS
La palabra “análisis” se refiere a una característica típicamente 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 solución del problema completo se obtiene como la suma de
las soluciones de los subproblemas de menor complejidad.

Lo anterior indica que la fase de análisis en un proyecto de construcción de software se

refiere a la especificación 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 especificación correctamente. Los miembros del grupo que trabajan con el
cliente para realizar el análisis y especificación 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 especificación, así
como la forma como el resto del grupo la entenderá. Esto sugiere el uso de un estándar para
realizar la fase de análisis del problema. En el caso del estándar de la ESA, el análisis se
divide en dos fases: especificación de requisitos de usuario y especificación de requisitos de
software. Los analistas deben liderar ambas fases.

Una de las razones más frecuentes del fracaso de un desarrollo de software es la de realizar
un análisis 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
características que el cliente desea. Ese error se repite una y otra vez, y se debe
básicamente a la inexperiencia del grupo de desarrolladores.

Actividades y metas
5
Actividad Integradora Desarrollo e Implementación de Sistemas
A continuación se detallan un conjunto de actividades para cada uno de las metas a lograr
por los analistas.

Actividades Metas
Entrevistar al cliente, ayudándole a identificar Determinar las necesidades esenciales y no
sus necesidades esenciales, así como las que son de segundo
nivel.
Verificar si los requisitos especificados son Impedir la introducción de defectos
los correctos. tempranamente en la construcción del
sistema.
Definir una estructura básica del sistema que
Construir el documento de especificación
incluya fuentes de información, módulos de
requisitos de usuarios
procesamiento de información, y resultados
esperados.
Realizar el análisis de los requisitos. Establecer una estructura básica inicial del
sistema.
Analizar la estructura básica del sistema. Establecer interacciones, interrelaciones y
sus contextos en dicha estructura.
Generar los diagramas de la arquitectura. Definir la especificación de la arquitectura del
sistema, en forma de un documento técnico
comprensible.

En la fase de análisis de requisitos de usuario, los analistas deben identificar las necesidades
del cliente, a través de reuniones con el cliente o su representante. En estas reuniones, los
analistas deben ayudar al cliente a definir los objetivos del sistema, determinando la
información que desea obtener, la información que será suministrada al sistema, las
funcionalidad del sistema y el rendimiento requerido. Los analistas deben determinar si cada
uno de los requisitos especificados es o no esencial. Luego los analistas deben determinar
información adicional requerida, tales como la evaluación de tecnología disponible para el
desarrollo y las tecnologías disponibles para el cliente. Debe considerar todos los recursos
especiales requeridos, las estimaciones del cliente y sus tiempos límites, así como factores
adicionales que puedan ser de interés.

Luego, los analistas deben realizar la especificación de requisitos de software. Esto es, no
como una especificación en lenguaje del cliente, sino que como especificación para el equipo
de trabajo.

El rol de analista es muy importante, debido a que el éxito del proyecto dependerá de una
buena especificación de requisitos. Es claro que los errores detectados en las fases de
análisis son más fáciles de detectar y corregir que en fases más avanzadas del desarrollo.
Una buena arquitectura debe ser robusta y flexible. Una falla en la estructura puede dar
6
Actividad Integradora Desarrollo e Implementación de Sistemas
origen al colapso del proyecto en forma parcial o total. Por lo anterior, se hace indispensable
realizar una buena detección de las necesidades del cliente y el establecimiento de una
buena estructura del sistema desde el principio.

Metodologías de análisis
El analista debe estructurar y especificar el problema del cliente, por lo que se espera que
mantengan un contacto estrecho. Durante el período de análisis, el analista se reunirá en
forma sistemática con el cliente con el propósito de entender y especificar el problema a
desarrollar. Dichas reuniones deben estar planificadas, con fecha de inicio y fecha de
término. En cada reunión, los analistas le mostrarán al cliente, como ha ido evolucionando el
documento de requisitos de usuario, DRU. El analista deberá asegurarse de que el cliente
entiende los conceptos ahí especificados. El analista podrá utilizar prototipos, encuestas,
otros sistemas, etc., con el propósito de ayudar a estructurar y definir el problema del cliente.
El proceso termina con el proceso de revisión de los requisitos de usuario RU/R, y luego, el
hito de aceptación del documento de requisitos de usuario, DRU.

El analista debe además, transformar los requisitos de usuario en requisitos de software, y

producir el documento de requisitos de software, DRS. La intervención del cliente en esta
etapa es menor, y su trabajo consistirá en resolver los conflictos detectados en los requisitos
de usuario por el analista durante el proceso de transformación. El proceso de especificación
de los requisitos de software produce el documento de requisitos de software, DRS. Luego,
se realiza una revisión formal RS/R y termina con el hito de aprobación del DRS.

Relación con otros roles

El rol de analista debe interactuar con los demás roles en el grupo. A continuación se
mencionan algunas de las interacciones.

• Administrador de proyecto: El analista debe interactuar con el administrador de proyecto

para estudiar la viabilidad del sistema a desarrollar. Esto es, verificar la realización 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. Es claro que la asignación
de actividades puede ir modificándose durante el proyecto.

• Diseñador: Los diseñadores deben interactuar con los analistas para determinar la
factibilidad del proyecto, y establecer los objetivos del sistema para un buen diseño. Los
analistas deben permanecer en contacto estrecho con los diseñadores debido a que
utilizarán la arquitectura del sistema. Los diseñadores deben poder ayudarle a los analistas.

• Programador: Los analistas son apoyados por los programadores en el entendimiento y

especificación de los requisitos de usuario y de software. Además, los apoyan en la
construcción de prototipos rápidos.

• Téster: Los analistas participan junto con los tésters en la revisión de los documentos de
análisis de requisitos.

7
Actividad Integradora Desarrollo e Implementación de Sistemas
Herramientas de apoyo
Resulta innecesario enumerar las herramientas disponibles para apoyar las fases de análisis,
debido a que hay muy pocas, las que no son de mucha utilidad. Esto, debido a que es muy
difícil tener una herramienta que detecte las necesidades del cliente. Este trabajo está más
bien relacionado con el criterio de los analistas. Estas herramientas administran los
requisitos, sus propiedades, y sus cambios.

Por otro lado, existen herramientas que apoyan a los analistas en tareas administrativas y en
el manejo de reuniones. Algunos ejemplos de esto son:
• Proyectores de diapositivas.
• Videograbadoras.
• Videocámaras, para grabar las reuniones para análisis posterior.
• Grabadoras de audio.

También debe considerarse herramientas para la creación de documentos, tales como

procesador de texto, software para el diseño y dibujo de diagramas, e incluso, sistemas
CASE para realizar la estructura general del sistema.

DISEÑADORES
Es el encargado de generar el diseño del sistema. Entre sus funciones está:
• Generar el diseño arquitectónico y diseño detallado del sistema, basándose en los
requisitos.
• Generar prototipos rápidos del sistema (con analistas y programadores) para chequear los
requisitos.
• Generar el documento de diseño arquitectónico de software (DDA), y mantenerlo
actualizado durante el proyecto.
• Velar porque el producto final se ajuste al diseño realizado (funciones de téster). En cada
disciplina de la ingeniería, el diseño acompaña el enfoque disciplinado que se utiliza para
inventar la solución de un problema, entregando así un camino entre los requisitos y la
implementación. En ingeniería de software, el propósito del diseño es la construcción de un
sistema que cumpla con los siguientes aspectos:

• Satisfaga una especificación funcional dada.

• Cumpla con las limitaciones del medio receptor del sistema.
• Cumpla requisitos implícitos y explícitos de rendimiento y uso de recursos.
• Satisfaga criterios de diseño implícitos y explícitos en la forma del artefacto construido.
• Satisfaga restricciones del mismo proceso de diseño, tal como su duración y costo, o las
herramientas disponibles para realizar el diseño.

Objetivos
El propósito del diseño es el de crear una estructura interna limpia y relativamente simple,
también llamada a veces una arquitectura. Un diseño es el producto final del proceso de
diseño. Así, una de las metas en el diseño de software es derivar una arquitectura del
sistema. Esta arquitectura sirve como un marco desde el cual se conducen más actividades
8
Actividad Integradora Desarrollo e Implementación de Sistemas
de diseño detallado.

Las buenas arquitecturas de software tienden a tener algunos atributos comunes. Entre ellos
se pueden mencionar los siguientes:

• Se encuentran construidos en niveles de abstracción bien definidos, provistos a través de

una interfaz bien definida y controlada, y construida sobre facilidades igualmente bien
definidas y controladas en niveles de abstracción inferiores.
• Existe una separación clara de preocupaciones entre la interfaz y la implementación de
cada nivel, haciendo posible cambiar la implementación de un nivel sin violar las
suposiciones que hicieron los clientes.
• La arquitectura es simple, comportamiento común se obtiene a través de abstracciones y
mecanismos comunes.

Actividades y metas
A continuación se describe las actividades y metas a considerar por un diseñador.

Actividades Metas
Descomposición de subsistemas. Crear una estructura interna del sistema,
llamada una arquitectura y la definición de
relaciones entre subsistemas.
Definir la administración de acceso a Seleccionar las políticas apropiadas para
recursos globales nombres lógicos, espacio, unidades físicas, y
acceso a datos compartidos.
Seleccionar una técnica de administración de Seleccionar el método de almacenamiento
almacenamiento de datos apropiado para las estructuras de datos, por
ejemplo, estructuras de datos vs. sistemas de
archivos vs. SGBD.
Interactuar con los programadores Seleccionar el lenguaje y paradigma
apropiado

Asignación de subsistemas a procesadores Asignar procesos a unidades de

procesamiento que sirva como plataforma
para la ejecución de subsistemas.
Administración de la concurrencia Identificar los casos donde la ejecución del
sistema incluya múltiples hebras de control
Selección de estrategias de control Determina el método apropiado para las
líneas de control de ejecución, por ejemplo,
procedural vs manejado por eventos vs
concurrente.
Administración de condiciones de borde Asegurarse que los módulos operan
apropiadamente en los bordes, establecidos
9
Actividad Integradora Desarrollo e Implementación de Sistemas
 para limitar o restringir procesos, por
ejemplo, inicializaciones, terminación, y
fallas.

Para evaluar la calidad de la representación del diseño, es necesario establecer criterios

técnicos para un buen diseño. A continuación se presenta una lista de criterios que pueden
utilizarse.
• Un diseño debe contener una organización jerárquica que haga un uso inteligente del
control entre los elementos del software.
• Un diseño debe ser modular. En otras palabras, el sistema debe estar particionado
lógicamente en elementos que realizan funciones y subfunciones específicas.
• Un diseño debe contener abstracciones de datos y abstracciones procedurales.
• Un diseño debe conducir a módulos (esto es, subrutinas o procedimientos), que muestren
características funcionales independientes.
• Un diseño debe considerar interfaces que reduzcan la complejidad de conexiones entre
módulos y con el ambiente externo.
• Un diseño debiese ser construido usando un método repetible, guiado por la información
obtenida durante la fase de requisitos de software.

Metodologías de diseño
Existen muchas metodologías de diseño. Describiremos brevemente sólo una clase de ellas,
llamado métodos de descomposición. El diseño de un sistema de software implica la
descomposición del sistema en partes de menor tamaño, cada una de las cuales puede
refinarse en forma independiente. Dentro de los métodos de descomposición,
mencionaremos los siguientes dos:

• Descomposición algorítmica: Corresponde al proceso de dividir el sistema en partes, cada

una de las cuales representa un pequeño paso de un proceso más grande. La aplicación de
métodos de diseño estructurado llevan a una descomposición algorítmica, cuyo foco está
puesto en el control de flujo del sistema.

• Descomposición orientada a objetos: Corresponde al proceso de dividir el sistema en

partes, cada una de las cuales representa una clase u objeto del dominio del problema. La
aplicación de métodos orientados a objetos llevan a descomposición orientada a objetos, en
la cual se observa al mundo como una colección de objetos que cooperan entre ellos para
obtener la funcionalidad deseada.

El proceso de diseño orientado a objetos considera el proceso de descomposición orientada

a objetos, así como una notación para representar los modelos lógico y físico del sistema en
diseño. También se incluyen los modelos estático y dinámico del sistema. Específicamente,
la notación incluye diagramas de clases, diagramas de objetos, diagramas de módulos y
diagramas de procesos.

Relación con otros roles

10
Actividad Integradora Desarrollo e Implementación de Sistemas
Los diseñadores deben relacionarse con otros miembros del equipo de desarrollo. A
continuación se describe algunas de las interacciones más relevantes:

• Administrador de proyecto: Los diseñadores trabajan bajo la coordinación del administrador

de proyecto para construir la arquitectura del sistema que cumpla con los requisitos bajo
restricciones dadas de presupuesto y disponibilidad de recursos humanos. Adicionalmente, el
administrador de proyecto utiliza las especificaciones de diseño para planificación y
estimación de recursos.

• Analista: Los diseñadores traducen la especificación de requisitos establecida en la fase de

análisis de requisitos de software en un modelo de implementación. Dentro de las tareas, los
diseñadores deben interactuar con los analistas para determinar requisitos ambiguos del
proyecto. Usualmente, los analistas apoyan a los diseñadores, y vice-versa.

• Programador: Los diseñadores crean la especificación de la implementación del sistema

para los programadores. Dicho modelo es traducido a código ejecutable por el computador.
Los diseñadores apoyan a los programadores en la selección del lenguaje de programación,
así como a la interpretación de los documentos de diseño tales como diagramas, cartas,
tablas, etc.

• Téster: Los diseñadores deben coordinar esfuerzos con los tésters para asegurar que el
diseño arquitectónico del sistema de software incluye especificaciones que ayuden en el
ejercicio de casos de testeo. Además, debe apoyar a los tésters en la verificación de
requisitos.

PROGRAMADORES
Los programadores deben convertir la especificación del sistema en código fuente ejecutable
utilizando uno o más lenguajes de programación, así como herramientas de software de
apoyo a la programación.

El éxito del desarrollo de software depende grandemente de conocimiento. Este

conocimiento no sólo corresponde a habilidades de programación y de administración de
proyectos, sino que a una percepción y entendimiento de los últimos desarrollos de la
industria del software. En los mercados actuales, rápidamente cambiantes y altamente
competitivos, se hace necesario conocer los últimos desarrollos, quien da soporte, y como
pueden beneficiar al proyecto y a la organización. A través de este conocimiento es que la
organización genera un camino hacia el éxito futuro.

Objetivos
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 reducción de la
complejidad del programa son:

• Menor cantidad de problemas de testeo.

11
Actividad Integradora Desarrollo e Implementación de Sistemas
• Aumento de la productividad de los programadores.
• Aumento de la eficiencia en la manutención del programa.
• Aumento de la eficiencia en la modificación del programa.
• Reducir el tiempo de codificación, aumentando la productividad del programador.
• Disminuir el número de errores que ocurren durante el proceso de desarrollo.
• Disminuir el esfuerzo de corregir errores en secciones del código que se encuentran
deficientes, remplazando secciones cuando se descubren técnicas más confiables,
funcionales o eficientes.
• Disminuir los costos del ciclo de vida del software.

Para alcanzar estos objetivos, es importante escoger las herramientas de desarrollo

apropiadas. De eso dependerá en parte poder alcanzar los objetivos, y por lo tanto, el éxito
del proyecto.

Es claro que para elegir las herramientas adecuadas, es necesario conocer el ambiente
donde el software va a correr.

Actividades y metas
A continuación se especifican algunas de las actividades y metas más relevantes de alcanzar
por los programadores.

Actividades Metas
Explorar los diferentes ambientes en que el Determinar los lenguajes posibles de usar e
sistema puede ser desarrollado identificar las posibles herramientas de
desarrollo
Interactuar con los analistas y diseñadores Seleccionar el ambiente apropiado

Explorar los diferentes lenguajes disponibles

Seleccionar el lenguaje apropiado
para el ambiente seleccionado

Interactuar con los diseñadores Seleccionar el lenguaje apropiado y lenguaje

de programación

Explorar diferentes herramientas de Seleccionar la herramienta de desarrollo

desarrollo (compiladores, depuradores, etc.) apropiada
disponibles para el lenguaje seleccionado
Explorar los distintos estilos de codificación
Escoger un estilo de codificación
que pueden ser utilizados en el lenguaje
seleccionado
Realizar la codificación del sistema Entregar el código ejecutable de acuerdo a
las fechas presupuestadas

12
Actividad Integradora Desarrollo e Implementación de Sistemas
Apoyar al ingeniero de testeo Realizar las actividades de testeo en forma
rápida, eficiente, sistemática, exhaustiva y
confiable, entregando un código utilizable y
seguro
Reunirse con otros miembros del equipo de Conocer el estatus de las actividades de
programadores programación, apoyando a sus colegas en
caso de requerirlo
Realizar revisiones personales Mantener el código eficiente y adaptable para
ser unido con el código de otros
programadores

El lenguaje de programación escogido afecta significativamente los costos, confiabilidad y

rendimiento del sistema. Ningún lenguaje es ideal para todas las aplicaciones. La elección
del lenguaje debe estar basada en la naturaleza de las aplicaciones (tiempo-real, incrustada,
procesamiento batch, basado en Web, etc.) y en la importancia de algunos indicadores de
calidad (rendimiento versus confiabilidad). La base de datos también debe ser confiable y
proteger privacidad e información comercial de usuarios no autorizados.

Los estilos de codificación incluyen los nombres de variables, la forma de hacer comentarios
en el código fuente, el diseño y escritura de rutinas y módulos, la creación de tipos de datos,
la selección y control de estructuras y la organización de bloques de instrucciones. A veces,
algunos de estos factores son determinados por la sintaxis y el paradigma de programación
utilizados, existiendo estándares para lo anterior.

Típicamente, un grupo de programadores, o una empresa, utiliza el mismo estándar con el

propósito de que todos los programadores puedan acceder fácilmente a todo el código. Las
modificaciones hechas al código deben ser solicitadas por el administrador de configuración.
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
aprobación 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
día al equipo sobre el estatus de la codificación, los problemas que tienen las otras personas,
la forma en que otras personas abordaron una tarea específica, nuevas necesidades internas
y cambios al código, y hacer revisiones al código de otros programadores.

Metodología
Existen diferentes metodologías para realizar las actividades de programación. Sin embargo,
todas ellas muestran un patrón común. Este patrón consiste en la exploración de
herramientas y lenguajes, la determinación del estilo de programación, el desarrollo de

13
Actividad Integradora Desarrollo e Implementación de Sistemas
herramientas utilitarias y rutinas comunes para administrar la entrada, salida y errores, la
codificación y depuración del sistema, la escritura de la documentación técnica, y para todo
el equipo de programadores, realizar revisiones personales periódicas y reuniones.

En la exploración de las herramientas y lenguajes, se debe considerar el tipo de aplicación y

su naturaleza, con el fin de determinar el lenguaje apropiado. Para realizar esta selección, se
debe considerar la metodología utilizada en las actividades de diseño así como el paradigma
de programación del lenguaje.

El desarrollo de las herramientas utilitarias y rutinas comunes debe realizarse antes de la

entrega del documento que contiene el diseño arquitectónico del sistema. Estos utilitarios
ayudan al programador a realizar la codificación más rápida debido a que puede focalizarse
sólo en la codificación de los factores especificados en el documento de diseño en vez de
ocupar tiempo en la codificación de otras rutinas que son necesarias en todo programa. En
estas funciones utilitarias, el programador debe construir algunas rutinas que considere
necesarias, dependiendo del tipo de aplicación.

Algunas herramientas de desarrollo han integrado herramientas que contienen rutinas

comunes para cada programa, así como rutinas para ambientes específicos. Este factor debe
ser considerado en la selección del lenguaje y herramientas de desarrollo.

Un factor muy importante en la construcción de un sistema es el paradigma de programación

utilizado. Uno de los paradigmas muy utilizados es el orientado a objetos, el cual tiene varias
ventajas sobre otras metodologías de programación. Así mismo, existen varias técnicas de
diseño y análisis orientado a objetos. Dicha elección es vital para la elección del lenguaje de
programación. Por ello, si la metodología de diseño utilizada es orientada al objeto, se
sugiere utilizar un lenguaje orientado a objetos.

En un equipo de programación, la revisión personal consiste en inspeccionar el código

escrito por otro programador, con el propósito de evaluarlo. La evaluación incluye buscar
errores de diseño, programación, estilo y documentación. De esa forma, es posible mantener
el código en forma más eficiente durante las actividades de programación, disminuyendo los
posibles problemas durante las actividades de integración. Las reuniones que se realizan son
de carácter informativo para determinar el estatus de la codificación.

Relación con otros roles

Los programadores deben relacionarse con otros miembros del grupo del proyecto. Dentro
de éstos, se encuentran los siguientes:

• Administrador de proyecto: El programador debe entregar un reporte con los resultados de

las actividades de programación cuando el administrador lo solicite. Debe además. Ayudarle
al administrador en la estimación de tiempos y costos de las actividades de programación.

• Analista: Deben interactuar con los analistas para determinar el ambiente apropiado para el
sistema.
14
Actividad Integradora Desarrollo e Implementación de Sistemas
• Diseñador: El rol de programador depende mucho del rol de diseñador, debido a que debe
utilizar herramientas adaptadas a la metodología utilizada en las actividades de diseño. El
diseñador también le ayuda al programador a seleccionar el lenguaje de programación
adecuado.

• Téster: El programador debe interactuar con el téster para determinar una forma apropiada
de construir los tests y de testear los programas. El programador debe estar presente
durante el testeo de código, cuando situaciones no esperadas suceden o es necesario
realizar pequeñas modificaciones al código.

• Administrador de configuración: El programador debe entregar la última versión del diseño

al administrador de configuración. El programador debe pedir la última versión del diseño al
administrador de configuración, debiendo atender los diferentes pedidos de cambio del
código. El programador puede solicitar cambios en otras partes del sistema a través del
administrador de la configuración. La petición se realiza llenando el formulario
correspondiente y enviándoselo al administrador de configuración.

Herramientas de apoyo
Existen muchas herramientas para ayudar al programador a desarrollar el sistema. Éstas
consisten principalmente en ambientes de desarrollo integrados adaptados para un lenguaje
de programación. Estos ambientes pueden compilar y ejecutar un programa usando
comandos para ello. La mayoría de estos ambientes también proveen herramientas para
depurar el programa. Algunos ambientes también proveen herramientas de scheduling.

TÉSTER
El desarrollo de un sistema de software requiere la realización de una serie de actividades de
producción. 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 errónea o imperfecta.
Por ello, el desarrollo de software considera una actividad que apoye el proceso de detección
y eliminación de los errores y defectos del sistema en construcción. El objetivo del rol de
téster es precisamente realizar dichas tareas.

El téster es el encargado de asegurar la calidad de cada uno de los productos (documentos,

prototipos, etc). Entre sus tareas están:
• Construir y aplicar los planes de prueba unitarios, de módulo, de sistema, y aceptación
parcial, manteniéndolos actualizados durante el proyecto.
• Velar por la completitud, y exactitud (no ambigüedades) de todos los documentos del
proyecto.
• Coordinar las inspecciones, y/o caminatas.
• Velar por la adhesión al estándar adoptado para el desarrollo.
• Velar por la calidad del producto final (cumplimiento de los requisitos).

Objetivos
15
Actividad Integradora Desarrollo e Implementación de Sistemas
El objetivo principal de la labor de téster es el de diseñar tests que en forma sistemática,
permita eliminar diferentes clases de errores, realizando esto con la mínima cantidad de
tiempo y esfuerzo.

Los objetivos específicos en la labor de un téster son los siguientes:

• Aplicar métodos para diseñar casos de tests efectivos.
• Construir buenos casos de tests que tengan altas probabilidades de encontrar errores aún
no descubiertos.
• Demostrar que las funciones del sistema parecen estar funcionando de acuerdo a sus
especificaciones.
• Proveer una buena indicación de la confiabilidad del software y algunas indicaciones de la
calidad del software.

Actividades y metas
Las actividades y metas a cumplir por los tésters se describen a continuación.

Actividades Metas
Participación en el proceso de especificación Prevenir errores en las etapas tempranas del
del sistema Interacción con el diseñador desarrollo
Interacción con el diseñador Realizar pruebas al diseño, obteniendo
índices de medición
Realizar las pruebas al código y Realizar diferentes pruebas, obtener una
componentes, apoyado por los buena interpretación de ellos, y realizar los
programadores. ajustes pertinentes.
Informar sobre los resultados obtenidos El grupo de desarrollo es informado sobre los
progresos y resultados obtenidos.

Metodología
Los tésters deben utilizar una metodología que en forma sistemática, organizada y
estructurada, les permita detectar y corregir, los errores y defectos introducidos en el proceso
de desarrollo del sistema. Típicamente, se utilizan dos técnicas para ello: el test de la caja
blanca y el test de la caja negra.

Los tests de caja blanca corresponden a un método de diseño de casos de tests que utilizan
la estructura de control del diseño procedural para derivar los casos de tests.

Usando este método, el téster puede derivar casos de tests para lo siguiente:
• Asegurarse que todos las trayectorias independientes en un módulo han sido visitadas al
menos una vez.
• Ejercitar todas las decisiones lógicas en sus lados verdadero y falso.
• Ejecutar todos los ciclos en sus límites y sobre sus límites operacionales.
• Ejercitar estructuras de datos internas para asegurar su validez.
16
Actividad Integradora Desarrollo e Implementación de Sistemas
Por otro lado, los tests de caja negra se focalizan en los requisitos de usuario del sistema. De
esa forma, este tipo de tests permite que los tésters generen conjuntos de datos de entrada
que ejercitarán completamente los requisitos del sistema. Los tests de caja negra no son una
alternativa a los tests de caja blanca. Más aún, 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 categorías:
• 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 inicialización y terminación.

Los tests de caja blanca son realizados tempranamente en el ciclo de vida del desarrollo. Los
tests de caja negra se utilizan en etapas más tardías del ciclo. Debido a que la metodología
de caja negra ignora las estructuras de control del programa, la atención se focaliza en el
dominio de la información.

Relación con otros roles

Los distintos miembros del grupo de trabajo deben relacionarse con los tésters. En cada rol,
la actividad de téster juega una parte importante. A continuación se menciona algunas
actividades relacionadas con otros roles:

• Analista: Participar en la revisión de los documentos de requisitos de usuario y de software.

• Diseñador: Coordinarse con el grupo de diseñadores para garantizar que el diseño

arquitectónico del producto de software incluye las especificaciones que facilitan el ejercicio
de los casos de tests. Además, debe coordinarse con los diseñadores en la verificación de
los requisitos. Por último, debe participar en las revisiones técnicas del diseño.

• Programador: El téster debe trabajar con el programador para realizar las siguientes
actividades: revisión de código; elección del mejor tipo de tests para aplicar al código; tests
de los métodos; tests de integración; tests de regresión.

• Validación y Verificación: El téster debe coordinarse con este rol en la ejecución de los
diferentes casos de tests, de acuerdo con las necesidades del cliente.

• Administrador de configuración: El administrador de la configuración debe proveerle al

téster de la última versión de documentos desarrollados por los otros roles (analista,
diseñador, programador).

17
Actividad Integradora Desarrollo e Implementación de Sistemas