Roles desarrollo software

Apuntes de Taller de Ingeniería de Software Apuntes de Taller de Ingeniería de Software

El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus
Capítulo 4: Roles en el desarrollo de software 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
Versión 1.3 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
4.1 Introducción capítulo.

El desarrollo de software es una actividad que, dada su complejidad, debe Es bastante común que, frente a una oferta de una empresa en busca de personal
desarrollarse en grupo. Además, esta actividad requiere de distintas capacidades, las calificado para su equipo de desarrollo de software, nos sintamos atraídos a postular a
que no se encuentran todas en una sola persona. Por ello, se hace necesario formar el un rol específico. Por ello, al final del capítulo se entrega, adicionalmente, algunas
grupo de desarrollo con las personas que cubran todas las capacidades requeridas. recomendaciones básicas para postular al cargo que se desee.
Cada una de esas personas aportará al grupo parte del total de las capacidades
necesarias para llevar a cabo con éxito el desarrollo.
4.2 La fábula de la granja
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 Un día cualquiera, los animales de una granja decidieron hacer una fiesta, con el
tradicionalmente se consideran en el desarrollo de software. Estos roles son propósito de pasar un momento agradable. Para organizar la fiesta, se reunieron el
administrador de proyecto, analista, diseñador, programador, téster, asegurador de mismo día en la mañana. Cada animal debía llevar algo a la fiesta. Como es lógico, a la
calidad, documentador, ingeniero de manutención, ingeniero de validación y vaca le pidieron la leche. A la gallina, le tocó llevar los huevos. Y al chancho, el tocino.
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, En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el chancho se
herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo. encuentra involucrado. Su participación le obliga a entregar parte de si mismo como
aporte para la fiesta. Al chancho le toca aportar una cuota de sacrificio mayor. Lo
Hay que señalar que es posible que no se requieran todos los roles en un desarrollo. anterior muestra la diferencia entre participar en un evento y estar involucrado.
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. Tomemos esta fábula para caracterizar a los miembros del grupo de un desarrollo de
Por otro lado, si el tipo del proyecto está enfocado más hacia la parametrización e software. ¿Cómo se comportan, en general? ¿Participan o están comprometidos en el
integración de sistemas, requerirá algunos roles en menor medida y otros en mayor. proceso de desarrollo de software?
Es posible también que una persona realice las labores de más de un rol al mismo Parece claro que lo deseable, desde el punto de vista del problema completo, es tener
tiempo. Esto, sobre todo en proyectos de desarrollo de software más pequeños. No integrantes comprometidos. Pero, ¿cómo se obtienen estos miembros comprometidos?
obstante, es imprescindible que dichas personas conozcan completamente todas sus ¿Es posible “crear” miembros del grupo comprometidos? ¿Administrador de proyecto
tareas. comprometido, analista comprometido, diseñador comprometido, programador
comprometido, téster comprometido, asegurador de calidad comprometido,
Por otro lado, también es posible la situación de tener más de una persona con un documentador comprometido, ingeniero de manutención comprometido, ingeniero de
mismo rol en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad validación y verificación comprometido, administrador de la configuración
mediana hemos utilizado con éxito la fórmula de tener un administrador de proyecto, comprometido y cliente comprometido?
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 La fábula anterior nos enseña la diferencia entre participar y estar comprometidos en
configuración son asumidas por todos los roles. Parte de las actividades de una actividad. Es claro que para tener miembros del equipo de desarrollo
aseguramiento de calidad son asumidas por el téster. El resto de las actividades no son comprometidos, es necesario capacitarlos en sus deberes y derechos en el ciclo de
realizadas. vida del desarrollo de software.

© 2003 David Fuller Padilla 1 © 2003 David Fuller Padilla 2


Es muy poco probable que un miembro no capacitado pueda estar comprometido con definidos. Los recursos asignados pueden ser recursos humanos, económicos,
los objetivos del proyecto. Este presentará claras deficiencias en el momento de tecnológicos, espacio físico, etc. En un proyecto, siempre debe existir un administrador.
participar en el proceso. Como ejemplo, se mencionan algunas: No obstante, un administrador puede dirigir más de un proyecto.

1. Un miembro no capacitado no entenderá el lenguaje técnico utilizado por el resto El administrador no es dueño de nada, es sólo un administrador temporal de los
de los miembros. Muchas veces, entenderá una cosa diferente a la expresada recursos. Como no es dueño de nada, debe dejarlos en la misma o mejor condición de
por sus pares. Esto es común debido a diferencias en el lenguaje. cómo los recibió. Por ello, el foco de una buena administración debe estar en el control
2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los y coordinación de los diferentes eventos y actividades de un proyecto. Adicionalmente,
problemas que se presentan durante el desarrollo. Sería muy bueno que el deben crearse las mejores condiciones posibles para que se realicen las actividades.
miembro pudiera aportar sus conocimientos en su dominio del problema durante
todo el ciclo de desarrollo del proyecto. Saber cuando exigir y cuando ceder. Una de las preocupaciones principales para los administradores debe ser el tener una
Conocer los estándares de desarrollo, de documentación, de aseguramiento de visión y misión claras del proyecto, trabajando para que ambas se cumplan. En otras
la calidad. palabras, el foco de un administrador de proyecto debe estar en el bosque más que en
3. Un miembro no capacitado no presupuesta su involucración en el proyecto, sólo los árboles. Sin embargo, debe cuidar cada árbol ya que cada uno de ellos contribuye
su participación. Este solo hecho reduce las posibilidades de éxito del proyecto. al bosque.
También aumenta los tiempos de desarrollo, disminuye la calidad del sistema,
aumentan los riesgos de rechazo del sistema por parte de la comunidad de El rol de administrador de proyecto es un rol muy importante, debido a que sus
clientes, etc. acciones y decisiones afectan al proyecto completo.

Lo anterior sugiere que es necesario contar con “miembros comprometidos” para
desarrollar correctamente el proyecto. Aspectos a considerar son los de crear un Objetivos
lenguaje común entre el equipo de desarrollo, así como hacer que entiendan
claramente sus deberes y obligaciones. Algunos de los objetivos de un administrador de proyecto son los siguientes:

Por otro lado, los clientes también deben estar comprometidos con el desarrollo. Eso 1. Tener el producto “a tiempo”, “bajo presupuesto” y con los requisitos de
significa que deben conocer el ciclo de vida escogido, cual es su participación en cada calidad definidos.
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 2. Terminar el proyecto con los recursos asignados.
activamente en la etapa de análisis, así como en todas aquellas actividades de revisión
y aceptación. 3. Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus
integrantes a cumplir sus objetivos particulares. Al final, se cumplirá el
En caso que el cliente no tenga dicha experiencia, se hace necesario que antes de un objetivo general.
desarrollo, se los capacite para convertirlos en clientes comprometidos. Lo anterior
requiere de trabajo, pero va en la senda correcta del éxito de un proyecto de software. 4. Cumplir con éxito las diferentes fases de un proyecto, utilizando herramientas
de administración.
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 5. Cumplir con las expectativas del cliente.
el equipo completo en torno a las metas a lograr, así como las cualidades y
características deseables de cada uno de ellos. Para ello, se requiere entender Algunos de los objetivos específicos a cumplir por un administrador de proyecto son los
correctamente las características de liderazgo dentro de un grupo humano. siguientes:

1. Comenzar y terminar cada actividad de acuerdo a lo planificado.
4.3 Administrador de proyecto
2. Lograr el mejor uso de los recursos disponibles.
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 3. Observar cada actividad para detectar y resolver inconvenientes.



En general:

• Realizar reuniones generales y seminarios de
Actividades y metas
evaluación y planificación.
• Realizar reuniones de evaluación con cada rol.
A continuación se muestra el conjunto de actividades a realizar por el administrador de • Obtener información sobre el estado el proyecto
proyecto para lograr cumplir con éxito las metas definidas. para el equipo y para el cliente.

Actividades Metas
Desarrollo eficiente de reuniones: Relación con otros roles
El administrador de proyecto está a cargo de las reuniones
y presentaciones entre el grupo y con los clientes. El administrador de proyecto debe relacionarse con todo el equipo de trabajo. Para ello,
debe darle apoyo con lo siguiente:
Debe conducir la reunión usando el protocolo establecido.
Debe cuidar de todos los aspectos de la reunión (layout de • Una carta de organización de todo el proyecto.
la sala, luces, sillas, mesas, computadores, proyección y Las reuniones logran sus objetivos. Los
sonido, pizarra, lápices, material que se entrega, etc.). Mida puntos principales de cada reunión deben
el tiempo y compárelo con lo planificado, para así ser documentados. • Un plan de trabajo general.
maximizar la eficiencia.
• Estimaciones de horas-hombre de cada actividad.
Cada reunión debe ser evaluada. De ser necesario, deben
tomarse acciones correctivas.
El administrador deberá tener una comunicación fluida con cada miembro del equipo
Promueva reuniones de integración (desayunos, comidas, para analizar problemas particulares, y si es necesario, tomar acciones correctivas. En
coffee breaks, etc.), donde el grupo pueda intercambiar particular, el administrador de proyecto deberá apoyar de la siguiente forma a cada rol:
puntos de vista y experiencias, creatividad y
espontaneidad.
Desarrollo organizacional: • Analistas: Trabajar con los analistas para estudiar las necesidades de los
clientes y los requisitos del sistema.
Conduzca reuniones y seminarios cuando el grupo
determina los próximos puntos: Asigne las actividades y el proyecto en un • Diseñadores: Trabajar con ellos para diseñar la arquitectura del sistema de
contexto amplio y con sentido para el grupo
acuerdo con los recursos asignados al proyecto. El administrador de proyecto
• Visión. de trabajo. Ayude al equipo en su
• Misión. desarrollo organizacional. requiere la arquitectura del sistema para determinar el plan de trabajo de los
• Metas. demás roles.
• Objetivos.
• Actividades. • 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
Administración: del sistema y de los recursos disponibles. Los resultados de los tests ayudan a
Entregar un plan de trabajo general basado en diagramas determinar el éxito del proyecto, preocupación principal de la administración de
Gantt y de flujo de actividades, apoyado con el plan de proyecto.
trabajo de cada rol.
• Aseguradores de calidad: La información provista por este rol ayuda a conocer el
El plan de trabajo general deberá contener estimaciones de
avance del proyecto. Este rol observa si cada una de las actividades se realiza
horas-hombre de cada actividad, que permita estimar los Coordine todas las actividades.
recursos humanos requeridos. de acuerdo a las especificaciones planificadas.

Desarrollar el contrato junto con el cliente. • Ingenieros de manutención: Generalmente la manutención utiliza una cantidad
muy importante de recursos del proyecto. Por ello, el administrador debe
Realizar actividades de organización, dirección y control.
conocer los planes de manutención, y de ser necesario, ajustarlos a los recursos
Trabajar con los analistas para estudiar las necesidades de disponibles.
los clientes y los requisitos del sistema.



• Documentadores: El administrador de proyecto tomará como referencia los • Organización: Distribuir eventos y actividades de acuerdo a los recursos y
documentos controlados por los documentadores para elaborar planes y la tiempos disponibles para llevar el proyecto al éxito.
evaluación del proyecto.
• Liderazgo: Llevar a un equipo a lograr sus objetivos.
• Clientes: El administrador de proyecto deberá administrar la relación con los
clientes, desarrollando una comunicación fluida con éstos, y siendo la cara • Experiencia: Haber estado en situaciones similares en el pasado.
visible del proyecto.
• Creatividad: Ser realista, tomando decisiones y tomando acciones cuando el
plan actual no funciona.
Herramientas de trabajo
• Persuasión: Encontrar y desarrollar argumentos para mejorar y ayudar en una
El administrador de proyecto deberá utilizar herramientas que apoyen su trabajo. situación.
Algunas de estas herramientas se describen a continuación:
Además, el administrador de proyecto deberá poseer las siguientes habilidades:
• 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 • Escuchar y comunicar.
electrónico y grupos de discusión también son herramientas de uso frecuente.
• Tomar decisiones y realizar acciones.
• Herramientas de administración de proyectos, que permitan definir y modificar
diagramas Gantt y de flujo de actividades. Ejemplos de esto son MS Project • Trabajar bajo presión.
2000 y MS Project Central, y Primavera.
Plan de trabajo
• Herramientas que permitan contabilizar el uso de recursos, tal como una planilla
de cálculos. Ejemplo de esto es MS Excel. A continuación se mencionan algunas de las actividades a realizar por el administrador
de proyecto, que forman parte de su plan de trabajo.
• Herramientas de presentación, tal como MS Power Point.
• Definir y establecer estándares a seguir por el grupo.
• Procesador de texto, tal como MS Word.
• Definir una estructura organizacional y hacer un diagrama organizacional.
• Grabadora de audio.
• Capacitar al grupo en las metodologías y estándares a utilizar.
• Grabadora de video.
• Crear un modelo de ciclo de vida para el proyecto.
Perfil de un administrador de proyecto
• Definir un plan y protocolo para desarrollo de reuniones.
El administrador de proyecto deberá tener, al menos, las siguientes capacidades
personales para desarrollar adecuadamente su trabajo: • Definir una agenda de reuniones con cada rol.

• Abstracción: Entender y comunicar aspectos no tangibles, como visión y misión • Construir un plan de trabajo específico que contenga diagramas Gantt y de flujo
del equipo de trabajo. Deberá además, poder entender y ver el proyecto de actividades.
completo como una unidad y sus relaciones entre sus partes.
• Definir protocolos para asignar y evaluar actividades. Nótese que durante el
• Concretización: Utilizando los recursos e información disponibles, obtener proyecto, será necesario redefinir tareas, y con ello, miembros del equipo
conclusiones y tomar acciones específicas para manejar el proyecto. deberán alterar su carga de trabajo para realizarlas.



• Realizar estimación de horas-hombre por actividad y por persona. Definir una estructura básica del sistema que incluya
fuentes de información, módulos de procesamiento Construir el documento de requisitos de usuarios.
de información, y resultados esperados.
• Realizar reuniones generales para evaluación y planificación. Realizar el análisis de los requisitos. Establecer una estructura básica inicial del
sistema.
• Realizar un contrato con el cliente que defina las características y condiciones Analizar la estructura básica del sistema. Establecer interacciones, interrelaciones y sus
en que se desarrollará el producto. contextos en dicha estructura.
Definir la especificación de la arquitectura del
Generar los diagramas de la arquitectura. sistema, en forma de un documento técnico
4.4 Analistas comprensible.

La palabra “análisis” se refiere a una característica típicamente relacionada con la En la fase de análisis de requisitos de usuario, los analistas deben identificar las
inteligencia humana. Esta se refiere a la habilidad de poder estudiar un problema de necesidades del cliente, a través de reuniones con el cliente o su representante. En
una complejidad determinada, descomponiendo el problema en subproblemas de estas reuniones, los analistas deben ayudar al cliente a definir los objetivos del sistema,
menor complejidad. De esa forma, la solución del problema completo se obtiene como determinando la información que desea obtener, la información que será suministrada
la suma de las soluciones de los subproblemas de menor complejidad. 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
Lo anterior indica que la fase de análisis en un proyecto de construcción de software se los analistas deben determinar información adicional requerida, tales como la
refiere a la especificación de un problema como la suma de subproblemas de menor evaluación de tecnología disponible para el desarrollo y las tecnologías disponibles
complejidad. Como el experto en el problema es el cliente, se hace necesario trabajar para el cliente. Debe considerar todos los recursos especiales requeridos, las
junto a él para realizar la especificación correctamente. Los miembros del grupo que estimaciones del cliente y sus tiempos límites, así como factores adicionales que
trabajan con el cliente para realizar el análisis y especificación del sistema a construir puedan ser de interés.
son precisamente los analistas.
Luego, los analistas deben realizar la especificación de requisitos de software. Esto es,
Para que el trabajo de los analistas tenga sentido para todos los integrantes del grupo, no como una especificación en lenguaje del cliente, sino que como especificación para
se hace necesario ponerse de acuerdo en la forma como se realizará la especificación, el equipo de trabajo.
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 El rol de analista es muy importante, debido a que el éxito del proyecto dependerá de
ESA, el análisis se divide en dos fases: especificación de requisitos de usuario y una buena especificación de requisitos. Es claro que los errores detectados en las
especificación de requisitos de software. Los analistas deben liderar ambas fases. 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
Una de las razones más frecuentes del fracaso de un desarrollo de software es la de estructura puede dar origen al colapso del proyecto en forma parcial o total. Por lo
realizar un análisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y anterior, se hace indispensable realizar una buena detección de las necesidades del
especificar el sistema que desea el cliente, los desarrolladores construyen sistemas cliente y el establecimiento de una buena estructura del sistema desde el principio.
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. Metodologías de análisis

Actividades y metas 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
A continuación se detallan un conjunto de actividades para cada uno de las metas a reunirá en forma sistemática con el cliente con el propósito de entender y especificar el
lograr por los analistas. 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á
Actividades Metas asegurarse de que el cliente entiende los conceptos ahí especificados. El analista
Entrevistar al cliente, ayudándole a identificar sus Determinar las necesidades esenciales y no
necesidades. esenciales, así como las que son de segundo
podrá utilizar prototipos, encuestas, otros sistemas, etc., con el propósito de ayudar a
nivel. estructurar y definir el problema del cliente. El proceso termina con el proceso de
Verificar si los requisitos especificados son los Impedir la introducción de defectos revisión de los requisitos de usuario RU/R, y luego, el hito de aceptación del documento
correctos. tempranamente en la construcción del sistema. de requisitos de usuario, DRU.



a que es muy difícil tener una herramienta que detecte las necesidades del cliente. Este
El analista debe además, transformar los requisitos de usuario en requisitos de trabajo está más bien relacionado con el criterio de los analistas. Estas herramientas
software, y producir el documento de requisitos de software, DRS. La intervención del administran los requisitos, sus propiedades, y sus cambios.
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 Por otro lado, existen herramientas que apoyan a los analistas en tareas
transformación. El proceso de especificación de los requisitos de software produce el administrativas y en el manejo de reuniones. Algunos ejemplos de esto son:
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. • Proyectores de diapositivas.

Relación con otros roles • Videograbadoras.

El rol de analista debe interactuar con los demás roles en el grupo. A continuación se • Videocámaras, para grabar las reuniones para análisis posterior.
mencionan algunas de las interacciones.
• Grabadoras de audio.
• Administrador de proyecto: El analista debe interactuar con el administrador de
proyecto para estudiar la viabilidad del sistema a desarrollar. Esto es, verificar la También debe considerarse herramientas para la creación de documentos, tales como
realización del sistema con los recursos disponibles. El administrador de procesador de texto, software para el diseño y dibujo de diagramas, e incluso, sistemas
proyecto le asignará a los analistas, la agenda con actividades a ser realizadas y CASE para realizar la estructura general del sistema.
sus fechas. Es claro que la asignación de actividades puede ir modificándose
durante el proyecto. Perfil de un analista

• Diseñador: Los diseñadores deben interactuar con los analistas para determinar Un analista es una persona con capacidades de comunicación, debido a que deberá
la factibilidad del proyecto, y establecer los objetivos del sistema para un buen tener un contacto estrecho con el cliente. Por lo mismo anterior, debe ser una persona
diseño. Los analistas deben permanecer en contacto estrecho con los sociable, expresando sus ideas en forma clara en un lenguaje común con el cliente.
diseñadores debido a que utilizarán la arquitectura del sistema. Los diseñadores También debe tener la capacidad de escuchar y entender al cliente. Se espera que los
deben poder ayudarle a los analistas. analistas tengan un alto grado de desarrollo de su inteligencia emocional.

• Programador: Los analistas son apoyados por los programadores en el Los analistas deben conocer y manejar perfectamente los métodos y las tecnologías de
entendimiento y especificación de los requisitos de usuario y de software. apoyo para realizar las fases de análisis. Además, se espera creatividad, lo que le
Además, los apoyan en la construcción de prototipos rápidos. permitirá establecer diferentes alternativas de modelos para la arquitectura del sistema
a construir.
• Téster: Los analistas participan junto con los tésters en la revisión de los
documentos de análisis de requisitos. También es importante que los analistas estén muy familiarizados con las técnicas de
diseño que se utilizarán en las siguientes fases. Además, se hace necesario que esté
• Asegurador de calidad: Debe revisar los documentos hechos por los analistas. familiarizado con los diferentes lenguajes de programación para ayudar a escoger el
apropiado para la construcción del sistema.
• Administrador de la configuración: Debe pedir los cambios pertinentes, evitando
errores a futuro. Plan de trabajo

• Documentador: Los analistas deberán entregarles la información que servirá A continuación se menciona algunas de las actividades a realizar por los analistas, las
para la documentación del sistema. que forman parte de su plan de trabajo.

Herramientas de apoyo • Preparar un documento con preguntas a realizar al cliente durante las
entrevistas.
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 • Determinar las fechas de reunión con el cliente.



requisitos y la implementación. En ingeniería de software, el propósito del diseño es la
• Generar un documento de especificación de requisitos de usuario en base a los construcción de un sistema que cumpla con los siguientes aspectos:
acuerdos alcanzados en la primera reunión.
• Satisfaga una especificación funcional dada.
• Presentación del documento de especificación al cliente en la siguiente reunión.
• Cumpla con las limitaciones del medio receptor del sistema.
• De ser necesario, realizar las modificaciones al documento de especificación de
requisitos de usuario y presentarlas al cliente en la próxima reunión. Repetir esta • Cumpla requisitos implícitos y explícitos de rendimiento y uso de recursos.
actividad las veces que sea necesario.
• Satisfaga criterios de diseño implícitos y explícitos en la forma del artefacto
• Estudiar la metodología de diseño. construido.

• Explorar las herramientas CASE a utilizar. • Satisfaga restricciones del mismo proceso de diseño, tal como su duración y
costo, o las herramientas disponibles para realizar el diseño.
• Generar los diagramas de arquitectura.
Objetivos
• Revisar los diagramas de arquitectura con los diseñadores.
El propósito del diseño es el de crear una estructura interna limpia y relativamente
• De ser necesario, realizar las modificaciones a los diagramas. 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
• Presentar los diagramas de arquitectura finales. arquitectura del sistema. Esta arquitectura sirve como un marco desde el cual se
conducen más actividades de diseño detallado.
• Construir el documento de requisitos de software.
Las buenas arquitecturas de software tienden a tener algunos atributos comunes. Entre
• Revisar el documento con los ingenieros de aseguramiento de la calidad y ellos se pueden mencionar los siguientes:
cliente, realizando modificaciones de ser necesario.
• Se encuentran construidos en niveles de abstracción bien definidos, provistos a
4.5 Diseñadores través de una interfaz bien definida y controlada, y construida sobre facilidades
igualmente bien definidas y controladas en niveles de abstracción inferiores.
Es el encargado de generar el diseño del sistema. Entre sus funciones está:
• Existe una separación clara de preocupaciones entre la interfaz y la
implementación de cada nivel, haciendo posible cambiar la implementación de
• Generar el diseño arquitectónico y diseño detallado del sistema, basándose en
un nivel sin violar las suposiciones que hicieron los clientes.
los requisitos.
• La arquitectura es simple, comportamiento común se obtiene a través de
• Generar prototipos rápidos del sistema (con analistas y programadores) para
abstracciones y mecanismos comunes.
chequear los requisitos.
Actividades y metas
• Generar el documento de diseño arquitectónico de software (DDA), y mantenerlo
actualizado durante el proyecto.
A continuación se describe las actividades y metas a considerar por un diseñador.
• Velar porque el producto final se ajuste al diseño realizado (funciones de téster). Actividades Metas
Descomposición de subsistemas Crear una estructura interna del sistema, llamada una
En cada disciplina de la ingeniería, el diseño acompaña el enfoque disciplinado que se arquitectura y la definición de relaciones entre subsistemas.
utiliza para inventar la solución de un problema, entregando así un camino entre los Definir la administración de acceso a Seleccionar las políticas apropiadas para nombres lógicos,
recursos globales espacio, unidades físicas, y acceso a datos compartidos.
Seleccionar una técnica de administración Seleccionar el método de almacenamiento apropiado para



de almacenamiento de datos las estructuras de datos, por ejemplo, estructuras de datos descomposición algorítmica, cuyo foco está puesto en el control de flujo del
vs. sistemas de archivos vs. SABD. sistema.
Interactuar con los programadores Seleccionar el lenguaje y paradigma apropiado
Asignación de subsistemas a Asignar procesos a unidades de procesamiento que sirva
procesadores como plataforma para la ejecución de subsistemas. • Descomposición orientada a objetos: Corresponde al proceso de dividir el
Administración de la concurrencia Identificar los casos donde la ejecución del sistema incluya sistema en partes, cada una de las cuales representa una clase u objeto del
múltiples hebras de control. dominio del problema. La aplicación de métodos orientados a objetos llevan a
Determina el método apropiado para las líneas de control de descomposición orientada a objetos, en la cual se observa al mundo como una
Selección de estrategias de control ejecución, por ejemplo, procedural vs manejado por eventos colección de objetos que cooperan entre ellos para obtener la funcionalidad
vs concurrente.
Asegurarse que los módulos operan apropiadamente en los deseada.
Administración de condiciones de borde bordes, establecidos para limitar o restringir procesos, por
ejemplo, inicializaciones, terminación, y fallas. 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
Para evaluar la calidad de la representación del diseño, es necesario establecer modelos lógico y físico del sistema en diseño. También se incluyen los modelos
criterios técnicos para un buen diseño. A continuación se presenta una lista de criterios estático y dinámico del sistema. Específicamente, la notación incluye diagramas
que pueden utilizarse. de clases, diagramas de objetos, diagramas de módulos y diagramas de
procesos.
• Un diseño debe contener una organización jerárquica que haga un uso
inteligente del control entre los elementos del software. Relación con otros roles

• Un diseño debe ser modular. En otras palabras, el sistema debe estar Los diseñadores deben relacionarse con otros miembros del equipo de desarrollo. A
particionado lógicamente en elementos que realizan funciones y subfunciones continuación se describe algunas de las interacciones más relevantes:
específicas.
• Administrador de proyecto: Los diseñadores trabajan bajo la coordinación del
• Un diseño debe contener abstracciones de datos y abstracciones procedurales. administrador de proyecto para construir la arquitectura del sistema que cumpla
con los requisitos bajo restricciones dadas de presupuesto y disponibilidad de
• Un diseño debe conducir a módulos (esto es, subrutinas o procedimientos), que recursos humanos. Adicionalmente, el administrador de proyecto utiliza las
muestren características funcionales independientes. especificaciones de diseño para planificación y estimación de recursos.

• Un diseño debe considerar interfaces que reduzcan la complejidad de • Analista: Los diseñadores traducen la especificación de requisitos establecida en
conexiones entre módulos y con el ambiente externo. 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
• Un diseño debiese ser construido usando un método repetible, guiado por la determinar requisitos ambiguos del proyecto. Usualmente, los analistas apoyan
información obtenida durante la fase de requisitos de software. a los diseñadores, y vice-versa.

Metodologías de diseño • 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
Existen muchas metodologías de diseño. Describiremos brevemente sólo una clase de por el computador. Los diseñadores apoyan a los programadores en la selección
ellas, llamado métodos de descomposición. El diseño de un sistema de software del lenguaje de programación, así como a la interpretación de los documentos
implica la descomposición del sistema en partes de menor tamaño, cada una de las de diseño tales como diagramas, cartas, tablas, etc.
cuales puede refinarse en forma independiente. Dentro de los métodos de
descomposición, mencionaremos los siguientes dos: • 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
• Descomposición algorítmica: Corresponde al proceso de dividir el sistema en especificaciones que ayuden en el ejercicio de casos de testeo. Además, debe
partes, cada una de las cuales representa un pequeño paso de un proceso más apoyar a los tésters en la verificación de requisitos.
grande. La aplicación de métodos de diseño estructurado llevan a una



• Asegurador de calidad: Los aseguradores de calidad deben revisar la fase de Plan de trabajo
diseño para asegurarse que el proceso de diseño sigue las normas de calidad
especificadas, y cumple con requisitos de rendimiento, diseño y verificación. El plan de trabajo de los diseñadores incluye las siguientes actividades para el diseño
del sistema.
• Ingeniero de validación y verificación: Los ingenieros de validación y verificación
evalúan el nivel de concordancia entre los requisitos de usuario y el modelo del • Organizar el sistema en subsistemas.
sistema diseñado, buscando desentendimientos, así como características
faltantes o erróneamente implementadas. La relación con los diseñadores es de • Identificar concurrencias inherentes al problema.
apoyo.
• Asignar los subsistemas a procesos y tareas.
• Administrador de configuración: Durante el diseño, el administrador de la
configuración de software controla los cambios en el diseño y mantiene registros • Seleccionar un administrador de datos.
completos de cada cambio y de sus razones.
• Identificar recursos globales y determinar mecanismos de acceso.
• Ingeniero de manutención: Los diseñadores deben apoyar al ingeniero de
manutención en administrar la evolución de post-venta. Esta evolución incluye • Elegir un enfoque para implementar el control de la ejecución.
arreglo de errores, mejoramiento de la funcionalidad del sistema, y modificación
de requisitos. • Considerar condiciones de borde.

• Documentador: Los documentadores mantienen los documentos de diseño una 4.6 Programadores
vez que el proceso de diseño es completado, haciendo disponibles dichos
documentos al resto del equipo de trabajo. 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
Herramientas de apoyo software de apoyo a la programación.

El éxito del desarrollo de software depende grandemente de conocimiento. Este
Perfil de un diseñador 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
El perfil de un diseñador debe incluir las siguientes características: la industria del software. En los mercados actuales, rápidamente cambiantes y
altamente competitivos, se hace necesario conocer los últimos desarrollos, quien da
• Para sistemas de tamaño pequeño y mediano, el diseño arquitectónico es soporte, y como pueden beneficiar al proyecto y a la organización. A través de este
realizado por una o dos personas calificadas. Deben mostrar habilidad inusual conocimiento es que la organización genera un camino hacia el éxito futuro.
para sintetizar soluciones construibles por sobre un gran conjunto de
restricciones.
Objetivos
• Generalmente son los más capacitados para realizar decisiones estratégicas
debido a su experiencia previa en la construcción de sistemas similares. 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
• No son necesariamente los desarrolladores con más experiencia. reducción de la complejidad del programa son:

• Deben tener habilidades de programación adecuadas. • Menor cantidad de problemas de testeo.

• Deben conocer muy bien la metodología de diseño utilizada, así como sus • Aumento de la productividad de los programadores.
herramientas de apoyo.
• Aumento de la eficiencia en la manutención del programa.



• Aumento de la eficiencia en la modificación del programa. Interactuar con el administrador de la configuración Mantener al día el control de la configuración
Realizar los cambios solicitados al código Mantener el software ejecutable eficiente
Hacer la documentación del código Entregar la documentación técnica del código fuente
Adicionalmente, otros objetivos importantes son:
El lenguaje de programación escogido afecta significativamente los costos,
• Reducir el tiempo de codificación, aumentando la productividad del programador.
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
• Disminuir el número de errores que ocurren durante el proceso de desarrollo.
aplicaciones (tiempo-real, incrustada, procesamiento batch, basado en Web, etc.) y en
la importancia de algunos indicadores de calidad (rendimiento versus confiabilidad). La
• Disminuir el esfuerzo de corregir errores en secciones del código que se base de datos también debe ser confiable y proteger privacidad e información
encuentran deficientes, remplazando secciones cuando se descubren técnicas comercial de usuarios no autorizados.
más confiables, funcionales o eficientes.
Los estilos de codificación incluyen los nombres de variables, la forma de hacer
• Disminuir los costos del ciclo de vida del software. 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
Para alcanzar estos objetivos, es importante escoger las herramientas de desarrollo instrucciones. A veces, algunos de estos factores son determinados por la sintaxis y el
apropiadas. De eso dependerá en parte poder alcanzar los objetivos, y por lo tanto, el paradigma de programación utilizados, existiendo estándares para lo anterior.
éxito del proyecto. 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
Es claro que para elegir las herramientas adecuadas, es necesario conocer el ambiente código.
donde el software va a correr.
Las modificaciones hechas al código deben ser solicitadas por el administrador de
Actividades y metas configuración. Otras veces, las modificaciones son solicitadas por el ingeniero de testeo
directamente al programador. En algunos casos, algunas modificaciones no requieren
A continuación se especifican algunas de las actividades y metas más relevantes de que se completen los formularios de cambio debido a que los cambios solicitados no
alcanzar por los programadores. 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
Actividades Metas
Explorar los diferentes ambientes en que el Determinar los lenguajes posibles de usar e
deben realizar cambios al software solicitados directamente por el cliente.
sistema puede ser desarrollado identificar las posibles herramientas de desarrollo
Interactuar con los analistas y diseñadores Seleccionar el ambiente apropiado Las reuniones realizadas entre programadores son muy importantes. En ellas se
Explorar los diferentes lenguajes disponibles para Seleccionar el lenguaje apropiado mantiene al día al equipo sobre el estatus de la codificación, los problemas que tienen
el ambiente seleccionado las otras personas, la forma en que otras personas abordaron una tarea específica,
Interactuar con los diseñadores Seleccionar el lenguaje apropiado y lenguaje de nuevas necesidades internas y cambios al código, y hacer revisiones al código de otros
programación
Explorar diferentes herramientas de desarrollo
programadores.
(compiladores, depuradores, etc.) disponibles para Seleccionar la herramienta de desarrollo apropiada
el lenguaje seleccionado Metodología
Explorar los distintos estilos de codificación que Escoger un estilo de codificación
pueden ser utilizados en el lenguaje seleccionado Existen diferentes metodologías para realizar las actividades de programación. Sin
Realizar la codificación del sistema Entregar el código ejecutable de acuerdo a las
embargo, todas ellas muestran un patrón común. Este patrón consiste en la exploración
fechas presupuestadas
Interactuar con los ingenieros de testeo Determinar las formas de realizar el testeo de herramientas y lenguajes, la determinación del estilo de programación, el desarrollo
Realizar las actividades de testeo en forma rápida, de herramientas utilitarias y rutinas comunes para administrar la entrada, salida y
Apoyar al ingeniero de testeo eficiente, sistemática, exhaustiva y confiable, errores, la codificación y depuración del sistema, la escritura de la documentación
entregando un código utilizable y seguro técnica, y para todo el equipo de programadores, realizar revisiones personales
Reunirse con otros miembros del equipo de Conocer el estatus de las actividades de periódicas y reuniones.
programadores programación, apoyando a sus colegas en caso de
requerirlo
Realizar revisiones personales Mantener el código eficiente y adaptable para ser En la exploración de las herramientas y lenguajes, se debe considerar el tipo de
unido con el código de otros programadores 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ñador: El rol de programador depende mucho del rol de diseñador, debido a
diseño así como el paradigma de programación del lenguaje. 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
El desarrollo de las herramientas utilitarias y rutinas comunes debe realizarse antes de seleccionar el lenguaje de programación adecuado.
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 • Téster: El programador debe interactuar con el téster para determinar una forma
puede focalizarse sólo en la codificación de los factores especificados en el documento apropiada de construir los tests y de testear los programas. El programador debe
de diseño en vez de ocupar tiempo en la codificación de otras rutinas que son estar presente durante el testeo de código, cuando situaciones no esperadas
necesarias en todo programa. En estas funciones utilitarias, el programador debe suceden o es necesario realizar pequeñas modificaciones al código.
construir algunas rutinas que considere necesarias, dependiendo del tipo de aplicación.
Algunas herramientas de desarrollo han integrado herramientas que contienen rutinas • Administrador de configuración: El programador debe entregar la última versión
comunes para cada programa, así como rutinas para ambientes específicos. Este del diseño al administrador de configuración. El programador debe pedir la
factor debe ser considerado en la selección del lenguaje y herramientas de desarrollo. ú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
Un factor muy importante en la construcción de un sistema es el paradigma de cambios en otras partes del sistema a través del administrador de la
programación utilizado. Uno de los paradigmas muy utilizados es el orientado a objetos, configuración. La petición se realiza llenando el formulario correspondiente y
el cual tiene varias ventajas sobre otras metodologías de programación. enviándoselo al administrador de configuración.

Así mismo, existen varias técnicas de diseño y análisis orientado a objetos. Dicha • Ingeniero de manutención: El programador tiene mucha influencia en el rol de
elección es vital para la elección del lenguaje de programación. Por ello, si la manutención, debido a que si el código está claro, será fácil de mantener.
metodología de diseño utilizada es orientada al objeto, se sugiere utilizar un lenguaje Dependiendo de las metodologías y herramientas empleadas, será más fácil o
orientado a objetos. más difícil mantener los sistemas.

En un equipo de programación, la revisión personal consiste en inspeccionar el código • Asegurador de calidad: El asegurador de calidad debe verificar la calidad del
escrito por otro programador, con el propósito de evaluarlo. La evaluación incluye sistema construido. El programador deberá entregarle su plan de trabajo al
buscar errores de diseño, programación, estilo y documentación. De esa forma, es asegurador de calidad.
posible mantener el código en forma más eficiente durante las actividades de
programación, disminuyendo los posibles problemas durante las actividades de • Documentador: El programador debe proveer la documentación técnica del
integración. código al documentador.
Las reuniones que se realizan son de carácter informativo para determinar el estatus de Herramientas de apoyo
la codificación.
Existen muchas herramientas para ayudar al programador a desarrollar el sistema.
Relación con otros roles Éstas consisten principalmente en ambientes de desarrollo integrados adaptados para
un lenguaje de programación. Estos ambientes pueden compilar y ejecutar un
Los programadores deben relacionarse con otros miembros del grupo del proyecto. programa usando comandos para ello. La mayoría de estos ambientes también
Dentro de éstos, se encuentran los siguientes: proveen herramientas para depurar el programa. Algunos ambientes también proveen
herramientas de scheduling.
• Administrador de proyecto: El programador debe entregar un reporte con los
resultados de las actividades de programación cuando el administrador lo Perfil de un programador
solicite. Debe además. Ayudarle al administrador en la estimación de tiempos y
costos de las actividades de programación. El perfil del programador requiere conocimiento en varios ambientes, pudiendo
ayudarle a los analistas y diseñadores a elegir el apropiado. Debe tener experiencia en
• Analista: Deben interactuar con los analistas para determinar el ambiente el desarrollo de aplicaciones en el ambiente seleccionado.
apropiado para el sistema.



Debe conocer diferentes lenguajes de programación disponibles para el ambiente aparezcan errores humanos. Dichos errores pueden empezar a aparecer desde el
seleccionado, y debe tener experiencia en el lenguaje de programación seleccionado. primer momento del proceso. Por ejemplo, los requisitos del sistema pueden ser
Las herramientas utilitarias desarrolladas en proyectos previos pueden ser útiles en el especificados en forma errónea o imperfecta. Por ello, el desarrollo de software
proyecto actual. Es preferible que el programador tenga conocimientos en diferentes considera una actividad que apoye el proceso de detección y eliminación de los errores
paradigmas de programación y estilos. y defectos del sistema en construcción. El objetivo del rol de téster es precisamente
realizar dichas tareas.
Debe además, conocer perfectamente las técnicas de diseño utilizadas por el
diseñador. También es deseable que el programador tenga conocimiento en varias El téster es el encargado de asegurar la calidad de cada uno de los productos
metodologías de diseño. (documentos, prototipos, etc). Entre sus tareas están:

Las bases de datos son una herramienta muy poderosa en un proyecto. Los • Construir y aplicar los planes de prueba unitarios, de módulo, de sistema, y
programadores deben tener experiencia en bases de datos. De ser posible, es aceptación parcial, manteniéndolos actualizados durante el proyecto.
preferible que los programadores tengan experiencia en el tipo de proyecto que se
desea realizar. • Velar por la completitud, y exactitud (no ambigüedades) de todos los
documentos del proyecto.

Plan de trabajo • Coordinar las inspecciones, y/o caminatas.

El plan de trabajo de los programadores debe contener, al menos, las siguientes • Velar por la adhesión al estándar adoptado para el desarrollo.
actividades:
• Velar por la calidad del producto final (cumplimiento de los requisitos).
• Explorar los diferentes ambientes de desarrollo.
Objetivos
• Explorar los diferentes lenguajes disponibles para el ambiente.
El objetivo principal de la labor de téster es el de diseñar tests que en forma
• Explorar las diferentes herramientas de desarrollo (compiladores, bases de sistemática, permita eliminar diferentes clases de errores, realizando esto con la
datos, depuradores, etc.) disponibles para el lenguaje seleccionado. mínima cantidad de tiempo y esfuerzo.

• Explorar sistemas ya construidos de los cuales, el nuevo sistema será parte. Los objetivos específicos en la labor de un téster son los siguientes:

• Elegir el estilo de programación. • Aplicar métodos para diseñar casos de tests efectivos.

• Programar las herramientas utilitarias y rutinas comunes. • Construir buenos casos de tests que tengan altas probabilidades de encontrar
errores aún no descubiertos.
• Codificar y depurar.
• Demostrar que las funciones del sistema parecen estar funcionando de acuerdo
• Testear. a sus especificaciones.

• Realizar revisiones personales y reuniones. • Proveer una buena indicación de la confiabilidad del software y algunas
indicaciones de la calidad del software.
• Escribir la documentación técnica.
Actividades y metas
4.7 Téster
Las actividades y metas a cumplir por los tésters se describen a continuación.
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 Actividades Metas



Participación en el proceso de especificación del Prevenir errores en las etapas tempranas del Los tests de caja blanca son realizados tempranamente en el ciclo de vida del
sistema desarrollo desarrollo. Los tests de caja negra se utilizan en etapas más tardías del ciclo. Debido a
Interacción con el diseñador Realizar tests al diseño, obteniendo índices de
que la metodología de caja negra ignora las estructuras de control del programa, la
medición
Realizar los tests, apoyado por los programadores Realizar diferentes tests, obtener una buena atención se focaliza en el dominio de la información.
interpretación de ellos, y realizar los ajustes
pertinentes Relación con otros roles
Informar sobre los resultados obtenidos El grupo de desarrollo es informado sobre los
progresos y resultados obtenidos 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
Metodología algunas actividades relacionadas con otros roles:
Los tésters deben utilizar una metodología que en forma sistemática, organizada y • Analista: Participar en la revisión de los documentos de requisitos de usuario y
estructurada, les permita detectar y corregir, los errores y defectos introducidos en el de software.
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.
• 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
Los tests de caja blanca corresponden a un método de diseño de casos de tests que
facilitan el ejercicio de los casos de tests. Además, debe coordinarse con los
utilizan la estructura de control del diseño procedural para derivar los casos de tests.
diseñadores en la verificación de los requisitos. Por último, debe participar en las
Usando este método, el téster puede derivar casos de tests para lo siguiente:
revisiones técnicas del diseño.
• Asegurarse que todos las trayectorias independientes en un módulo han sido
• Programador: El téster debe trabajar con el programador para realizar las
visitadas al menos una vez.
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.
• Ejercitar todas las decisiones lógicas en sus lados verdadero y falso.
• Validación y Verificación: El téster debe coordinarse con este rol en la ejecución
• Ejecutar todos los loops en sus límites y sobre sus límites operacionales. de los diferentes casos de tests, de acuerdo con las necesidades del cliente.
• Ejercitar estructuras de datos internas para asegurar su validez. • 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
Por otro lado, los tests de caja negra se focalizan en los requisitos de usuario del otros roles (analista, diseñador, programador).
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 Perfil de un téster
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. El perfil de un téster debe considerar las siguientes características:
Los tests de caja negra tratan de encontrar errores en las siguientes categorías:
• Ser un buen programador en el lenguaje seleccionado, y tener experiencia en el
desarrollo de sistemas.
• Funciones incorrectas o faltantes.
• Conocer bien la metodología de diseño utilizada.
• Errores de interfaces.
• Ser sistemático en las revisiones de código y resultados de los tests.
• Errores en estructuras de datos o acceso a bases de datos externas.
• Tener una personalidad agresiva para buscar errores en el código y documentos
• Errores de rendimiento del sistema y errores de inicialización y terminación. del proyecto.



• Debe además tener una personalidad alegre, debido a que debe relacionarse
con gran parte de los miembros del equipo de desarrollo. Actividades Metas
Asegurarse que la especificación de requisitos es una
Revisar los documentos de requisitos de representación correcta y completa de las expectativas del
Plan de trabajo usuario y de software cliente, y que es suficientemente clara para el equipo de
desarrollo, especialmente para los diseñadores.
El plan de trabajo del téster debe incluir, al menos, las siguientes actividades: Revisar el plan de administración del Asegurarse que el plan es creado y se cumple.
proyecto
• Participar en la revisión de los requisitos del sistema. Asegurarse que el plan se crea, que es adecuado al
Revisar el plan de testeo proyecto específico, y que se sigue en cada fase del ciclo
hasta que se entrega el producto.
• Construir un plan de testeo. Revisar la fase de diseño arquitectónico Asegurarse que los diseñadores seleccionaron la
metodología apropiada y que el producto final cumple con
• Coordinarse con los diseñadores para incluir el test del diseño en el documento. los requisitos de rendimiento, diseño y verificación.
Revisar la fase de diseño detallado Asegurarse que el software producido cumple con los
requisitos especificados y con los atributos de calidad
• Ejecutar los tests de bajo nivel. impuestos.
Revisar las políticas de control de cambios, Asegurarse que se realizan monitoreos de errores en cada
• Ejecutar los tests de mediano nivel. control de errores y control de la fase del desarrollo y que se respaldan las líneas bases
configuración haciendo que el producto no se pueda perder.
Revisar la documentación Asegurarse que la documentación cumple con el estándar
• Ejecutar los tests de alto nivel. utilizado durante el desarrollo del producto de software.

• Construir la documentación del proceso de tests. Metodología

4.8 Aseguradores de calidad De entre las actividades del Asegurador de Calidad, la más importante es la de
participar en las revisiones técnicas formales (RTF). Si estas revisiones están bien
En la actualidad, los factores dominantes en la administración de proyectos de software conducidas, son la forma más efectiva de encontrar, revelar y corregir errores mientras
son los tiempos y costos de desarrollo. Existen buenas razones para ello. Los tiempos aún es barato encontrarlos y arreglarlos.
y costos de desarrollo son con frecuencia, muy grandes. Por ello, la administración se
ha concentrado en tratar de resolver dichos problemas. Sin embargo, existe un gran El estándar ESA incluye revisiones en las fases RU/R, RS/R, DA/R y DD/R. No
peligro en esto. En la medida que crece la presión por cumplir con las fechas obstante, las RTFs son especialmente requeridas en la fase de diseño arquitectónico.
estipuladas, y reducir los costos, es la calidad del producto la que sufre. Cuando se Esto, debido a que las actividades de diseño introducen entre el 50 y 65% de todos los
acelera el desarrollo de un sistema que está atrasado, generalmente se corta todo lo errores durante el proceso de desarrollo. Se ha demostrado que las RTFs descubren
que no se considere “esencial”, usualmente cortando las actividades de verificación y del orden del 75% de los errores de diseño.
testeo, resultando en un producto de calidad reducida.
Los objetivos de las RTFs son: 1. descubrir errores en funciones, lógica e
Se hace necesario encontrar una nueva ecuación para el desarrollo de software. No implementación en cualquiera de las representaciones del software; 2. verificar que el
debe ser simplemente “producto de software = a tiempo + dentro de los costos”. software bajo revisión cumple con los requisitos; 3. asegurarse que el software ha sido
Debiese ser “producto de software = calidad + a tiempo + dentro de los costos”. Para representado de acuerdo al estándar en uso; 4. alcanzar software que es desarrollado
ello, debe existir el convencimiento individual y de la gerencia de considerar la calidad en forma uniforme; y 5. hacer el proyecto más manejable.
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. Una RTF es una reunión entre tres a cinco personas. Cada una de ellas ha realizado
Típicamente, dichos atributos se encuentran definidos en la forma de un estándar, el una preparación de antemano de no más de dos horas, y su duración no debe tampoco
que debe cumplirse. sobrepasar las dos horas. La RTF se focaliza en un producto pequeño del software, tal
como una porción de los requisitos, el diseño detallado de un módulo, o el listado de
Actividades y metas código fuente de un módulo.

A continuación se presentan las actividades y metas a cumplir por los aseguradores de Los participantes de una RTF son el productor (la persona que desarrolló el producto a
calidad. revisar), un encargado de la revisión que evalúa el producto genera copias de material,



y lo distribuye a dos o tres revisores para que se preparen de antemano. Uno de los El asegurador de calidad debe ser una persona con mucha experiencia en proyectos
revisores toma el rol de documentador de los aspectos más relevantes aparecidos de desarrollo de software, con conocimientos suficientes sobre técnicas que aseguren
durante la revisión. la calidad de un producto de software. Lo anterior lo hace capaz de negociar con la
calidad del producto, y ocasionalmente, modificar el criterio de los desarrolladores.
Al final de la revisión, los participantes deben decidir si: 1. aceptar el producto sin
modificación posterior; 2. rechazar el producto debido a errores serios; o 3. aceptar el Plan de trabajo
producto con errores menores que deben ser corregidos, pero no se requiere una
revisión posterior. El plan de trabajo de un asegurador de calidad es extenso, ya que debe estar
involucrado en todas las fases del desarrollo del software.
Relación con otros roles
4.9 Administrador de configuración
A continuación se analiza la relación del asegurador de calidad con los otros roles:
La administración de la configuración es una disciplina que tradicionalmente se aplica
• Administrador de proyecto: El asegurador de calidad revisa el plan de al desarrollo de sistemas de hardware, al desarrollo de elementos de hardware o
administración de proyecto, para asegurarse que se crea y que se sigue. sistemas de hardware/software. La administración de la configuración de software
corresponde a la administración de la configuración aplicada a un sistema, o a partes
• Analista: El asegurador de calidad revisa la especificación de requisitos de de un sistema, predominantemente correspondiente a software. Su aplicación, en
usuario y de software, para asegurarse que es una representación correcta y conjunto con otras disciplinas, lleva al desarrollo de sistemas en forma ordenada y
completa de las expectativas del cliente, y que es suficientemente clara para estructurada.
todos en el grupo de desarrollo, especialmente para el diseñador.
La administración de la configuración es una disciplina que aplica dirección y vigilancia
• Diseñador: El asegurador de calidad revisa la fase de diseño arquitectónico, técnica y administrativa a:
para asegurarse que el diseñador seleccionó la metodología apropiada y que el
producto final de esta fase cumple con requisitos de rendimiento, diseño y • Identificar y documentar las características funcionales y físicas de items de
verificación. configuración.

• Programador: El asegurador de calidad revisa la fase de diseño detallado, para • Auditar los items de configuración para verificar cumplimiento de
asegurarse que el código producido cumple con la especificación de requisitos especificaciones, control de interfaces y documentos, así como otros requisitos
establecida y que cumple con los atributos de calidad en uso. adicionales que pueda definir el contrato.

• Téster: El asegurador de calidad revisa el plan de testeo, para asegurarse que • Controlar cambios a los items de configuración y su documentación relacionada.
es creado, que es adecuado para el proyecto específico, y que se aplica en cada
fase del proceso de desarrollo hasta la entrega del producto. • Registrar y reportar información necesaria para administrar items de
configuración en forma efectiva, incluyendo el estatus de cambios propuestos y
• Documentador: El asegurador de calidad revisa la documentación, para el estatus de implementación de cambios aprobados.
asegurarse que corresponde con el software desarrollado, y que cumple con el
estándar en uso. • Mantener el repositorio del proyecto actualizado con las últimas versiones de
todos los entregables del proyecto.
• Administrador de configuración: El asegurador de calidad revisa los registros de
cambios, errores y de configuración, para asegurarse de que los cambios han • Administrar el software utilizado para el control de versiones.
sido implementados apropiadamente, y que las líneas bases son almacenadas y
que el producto no se puede perder. • Definir y controlar perfiles de acceso a los archivos del proyecto.

Perfil de un asegurador de calidad • Velar por la completitud y exactitud del repositorio del proyecto.



Los problemas de software más frustrantes son frecuentemente ocasionados por una elementos involucrados en la disciplina de la administración de la configuración de
pobre administración de la configuración. Los problemas son frustrantes debido a que software, es necesario formular un concepto de software. Digamos que software es
requieren tiempo para arreglarlos, y usualmente ocurren en el peor momento, y son información que es:
totalmente innecesarios.
• estructurada con propiedades lógicas y funcionales;
La administración de la configuración ayuda a reducir estos problemas coordinando los
productos de muchas personas que trabajan en un proyecto común. Sin ese control, su • creada y mantenida en varias formas y representaciones durante su ciclo; y
trabajo va a producir conflictos con frecuencia, resultando en problemas como los
descritos a continuación: • ajustada para procesamiento de máquina en su estado completamente
desarrollado.
• Modificaciones simultáneas. Cuando dos o más personas trabajan
separadamente en el mismo programa o documento, el último en realizar los El hecho de que, en general, el software es fácil de modificar tiene implicaciones
cambios puede fácilmente destruir el trabajo del otro. importantes para la administración de la configuración de software. Esta susceptibilidad
al cambio, esta plasticidad. Es la razón primaria para disciplinar el proceso de
• Código común. En grandes sistemas, cuando se modifican funciones comunes desarrollo de software. Así, el software puede existir en dos formas básicas:
de un programa, es necesario notificarlo a todos los miembros del grupo. Sin
una administración de código efectiva, no hay forma de estar seguro de • Una forma no ejecutable: documentación tal como la especificación de funciones
encontrar y alertar a cada uno de los miembros del equipo. a ejecutar, cartas de flujo que diagraman la lógica de las funciones a ejecutar,
etc.
• Versiones. Muchos de los grandes programas son desarrollados en releases
evolucionarios. Con uno siendo utilizado por el usuario, otro en testeo, y un • Una forma ejecutable: consiste en secuencias ejecutables de información
tercer en desarrollo, los arreglos de errores deben ser propagados entre ellos. directamente accesibles por una suite dada de maquinaria computacional.
En sistemas de gran tamaño con varios releases activos en forma simultánea y
muchos programadores trabajando en arreglo de errores y mejoras, los Para los propósitos de la administración de la configuración de software, estas dos
conflictos y confusión son bastante frecuentes. formas de software son equivalentes. La primera forma es necesaria para describir el
software, facilitando la comunicación del usuario con el computador. La segunda forma
Estos problemas conducen a confusión y pérdida de control, y pueden hacer perder es necesaria para ejecutar el software en un computador.
una gran cantidad de tiempo. La clave es tener un sistema de control que conteste a
las siguientes preguntas: Los elementos que componen la administración de configuración de software son:

• ¿Cuál es mi configuración de software actual? • Identificación de la configuración. Corresponde a una disciplina para identificar la
configuración de un ítem, documentando sus características funcionales y
• ¿Cuál es mi estatus? físicas.

• ¿Cómo controlo cambios en mi configuración? • Auditoria de configuración. Provee los mecanismos para determinar una línea
base formalmente establecida.
• ¿Cómo le informo al resto de mis cambios?
• Control de configuración. Es la ejercitación de procedimientos establecidos para
• ¿Qué cambios han sido hechos a mi software? clasificar, aprobar o reprobar, liberar, implementar y confirmar cambios
aprobados a especificaciones y líneas base.
• ¿Los cambios realizados por otros afectan mi software?
• Contabilidad del estatus de configuración. Contabilidad de configuración es el
La administración de configuración de software, es una disciplina que identifica la registro y reporte de datos relacionados con la identificación de la configuración,
configuración de un sistema en puntos discretos en el tiempo, con el propósito de estatus de aprobación de cambios propuestos y estatus de implementación de
controlar sistemáticamente los cambios a esa configuración, manteniendo integridad y cambios aprobados durante todas las fases del proyecto.
trazabilidad de la configuración a través del ciclo de vida del sistema. Para entender los



Objetivos incluyendo el estatus de los cambios propuestos y el líneas bases.
estatus de implementación de los cambios aprobados.
Mantener un registro de cómo evolucionó el sistema y
El objetivo principal de la administración de configuración de software es la
donde está el sistema en cualquier instante respecto a
administración efectiva del ciclo de vida del sistema de software y la evolución de su su línea base y acuerdos escritos. Esta actividad es la Verificar cual es la configuración de software
configuración. En otras palabras, corresponde al establecimiento y manutención de los Contabilidad del Estatus de la Configuración de actual y cual es su estatus.
productos de software del proyecto a través del ciclo de vida del software. La Software, y provee los medios para seguir la historia del
administración de configuración no es una tarea independiente, existe para apoyar el ciclo de vida del sistema de software.
desarrollo y manutención del producto de software. Es necesario utilizar el criterio al Auditar los items de configuración. Auditar la
configuración de software provee los mecanismos para Verificar cumplimiento de especificaciones,
aplicar técnicas de administración de configuración. Por un lado, muy poca determinar el grado en el cual el estado actual del documentos de control de interfaces, y otros
administración de la configuración y es posible perder productos, necesitando trabajo sistema de software refleja el sistema de software requisitos de contratos.
adicional para rehacerlos. Por otro lado, mucha administración de la configuración y la dibujado en la línea base y documentación de requisitos.
organización nunca producirá un producto, debido a que estará muy ocupada moviendo También provee los mecanismos para establecer
papeles. formalmente una línea base.

Actividades y metas Metodología

A continuación se muestran parte de las actividades y metas del administrador de La administración de configuración de software es una actividad paraguas que es
configuración. aplicada a través del proceso de ingeniería de software completo. Dichas actividades
son desarrolladas para: identificar el cambio, controlar el cambio, asegurarse que el
Actividades Metas cambio se implementó adecuadamente, y reportar cambios a personas que puedan
Preparar el Plan de Administración de la Configuración Se planifican las actividades de estar interesadas. Los items que componen toda la información producida como parte
de Software de acuerdo al estándar en uso administración de la configuración de del proceso de ingeniería de software se le llama en forma conjunta, configuración de
software. software. Los cambios pueden ocurrir en cualquier momento, y por cualquier razón.
Las tareas iniciales son identificar las líneas base que
serán usadas en el proyecto, y los items que serán parte
de cada línea base. Este proceso se llama identificación Relación con otros roles
de la configuración. En el sentido de la administración de Se identifican las características funcionales y
la configuración, una línea base es un documento, o un físicas de los items de configuración. El administrador de la configuración de software se relaciona con todos los integrantes
conjunto de ellos, formalmente designados y fijados en el de su equipo de una o más de las siguientes formas:
tiempo. Por ello, una línea base es un repositorio oficial
del producto, y contiene la versión más reciente.
Para alcanzar esta meta, el control de la configuración • Si los roles producen un ítem de configuración de software que ha sido
de software provee el mecanismo administrativo para identificado y puesto en el repositorio de administración de la configuración de
precipitar, preparar, evaluar y aprobar o reprobar el software.
procesamiento de propuestas de cambio. Incluye 3
actividades básicas:
• Si pertenecen al Cuerpo de Control de Cambios.
• Establecer y diseñar la documentación requerida
para formalmente precipitar y definir un cambio Se controlan los cambios. • Si solicitan un cambio de ítem de la configuración de software.
propuesto a un sistema de software (Propuesta
de Cambio de Ingeniería, PCI). • Si la persona debe implementar un cambio.
• Formar un cuerpo organizacional para
formalmente evaluar y aprobar o reprobar un
cambio propuesto a un sistema de software Si uno de los eventos anteriores ocurre, estas personas deben realizar las actividades
(Cuerpo de Control de Cambio, CCC). correspondientes de acuerdo al Plan de Administración de Configuración de Software.
• Realizar los procesos para controlar cambios a Además, deben saber que la administración de la configuración de software es un
un sistema de software. punto central en cualquiera de esas actividades.
Realizar RTFs y/o auditorias de configuración de Asegurarse que los cambios se implementan
software. Éstas son los medios para asegurar que el apropiadamente.
cambio se implementó correctamente. Específicamente, la relación con cada uno de los roles es:
Registrar y reportar información requerida para Los grupos afectados y personas son
administrar items de configuración eficientemente, informados del estatus y contenido de las



• Administrador de proyecto: Su plan será parte del repositorio de administración • Debe estar familiarizado con la mayoría de las áreas de administración
de la configuración de software. Además, él es parte del CCC. funcional, y el conocimiento de los programas necesariamente debe llevarlo a
construir un sistema de administración de la configuración adecuado.
• Analista: Los ítems de configuración de software producidos por este rol son el
DRU y el DRS. • Debe tener en mente que es como la conciencia del programa, o policía,
exigiendo revisión completa y decisiones oficiales antes de que se realicen
• Diseñador: Los ítems de configuración de software producidos por este rol son el cambios a lo contratado.
DDA y el DDD. Por lo tanto, el diseñador es parte del CCC.
• Debe mantener los principios de la administración de configuración visibles y
• Programador: Los ítems de configuración de software producidos por este rol aplicarlos como se definió.
son parte del DDD y el código del sistema (fuente y ejecutable). Este rol es parte
del CCC. Plan de trabajo

• Téster: El único ítem de configuración de software producido por este rol es el En el plan de trabajo del administrador de configuración figuran las siguientes tareas:
Plan de Testeo.
• Planificar las actividades principales de la administración de configuración de
• Asegurador de calidad: El ítem de configuración de software producido por este software, y como se realizarán durante el ciclo de vida del software.
rol es el Plan de Aseguramiento de la Calidad.
• Escribir un Plan de Administración de Configuración de Software.
• Validación y verificación: El ítem de configuración de software producido por este
rol es el Plan de Validación y Verificación. Este rol es parte del CCC. • Elaborar las plantillas necesarias para solicitar un cambio: Propuesta de Cambio
de Ingeniería.
• Documentador: El único ítem de configuración de software producido por este rol
es su plan. • Diseñar y elaborar el repositorio central para mantener los items de
configuración de software identificados.
• Ingeniero de manutención: Este rol produce los siguientes items de
configuración de software: Plan de Manutención, y además es responsable de • Estudiar las herramientas que serán usadas para acceder al repositorio.
implementar los cambios debido a cambios pedidos al software después de la
fase de diseño detallado. • Una vez que el proyecto empiece, debe realizar las cinco actividades principales
durante el ciclo de vida del software:
Perfil de un administrador de configuración
o Identificación de configuración de software.
Las personas en este rol deben poder manejar tres elementos: actividades
administrativas, auxiliares (registrar eventos), y técnicas. El administrador de o Control de versiones.
configuración debe disponer de los recursos para hacer efectiva una solución. Estos
recursos pueden ser experiencia, mano de obra o autoridad. Idealmente, debiesen ser o Control de cambios de software.
las tres. Un administrador efectivo tiende a influir el resultado de un evento en forma
positiva y productiva. o Auditorias de configuración de software.

Un administrador de configuración puede obtener experiencia y crear un buen perfil de o Contabilidad del estatus de configuración de software.
su rol de la siguientes formas:
4.10 Ingeniero de validación y verificación
• Recibir entrenamiento. No significa que deba recibir entrenamiento exhaustivo,
pero si debe conocer las funciones principales de la administración de la Una de las metas necesarias de tener en cuenta en toda organización de desarrollo de
configuración de software y sus técnicas. software que se considere exitosa es que el software que evoluciona, continúe
satisfaciendo las expectativas de los usuarios durante dicho proceso. Para lograr esta



meta, es necesario aplicar prácticas de ingeniería de software durante la evolución del
producto. La mayoría de estas prácticas tratan de crear y modificar software de forma Objetivos
de maximizar la probabilidad de satisfacer las expectativas de sus usuarios. Otras
prácticas tratan de asegurar que el producto cumplirá con las expectativas de dichos El objetivo principal del proceso de V&V de software es el de analizar y testear en
usuarios. Estas últimas son ampliamente conocidas como la validación y verificación de forma completa el software durante el desarrollo para determinar que ejecuta su
software (V&V). funcionalidad correctamente, asegurarse que no ejecuta funciones no intencionalmente
definidas y proveer información sobre su calidad y confiabilidad.
Validación se refiere al proceso de evaluación del software al final de su proceso de
desarrollo para asegurarse que está libre de fallas y cumple con sus requisitos. Una Dependiendo de las actividades de V&V respecto a la funcionalidad y rendimiento del
falla se define como un comportamiento incorrecto del producto. Validación se refiere al software, es posible identificar algunos objetivos:
proceso de determinar si el producto en una determinada fase del proceso de
desarrollo cumple con los requisitos establecidos en la fase anterior. • Correctitud: En que grado el producto está libre de fallas.

V&V es una ayuda para determinar que los requisitos de usuario han sido • Consistencia: En que grado el producto es consistente consigo mismo y con
implementados correcta y completamente, y existen trazas a los requisitos del resto de otros productos.
las fases. El objetivo principal del proceso de V&V es el de analizar y testear el
software en forma completa durante el desarrollo para determinar que el software • Necesidad: En que grado lo que hay en el producto es necesario.
ejecute sus funcionalidad correctamente, asegurarse que no ejecute funciones no
definidas, y proveer información sobre su calidad y confiabilidad. En otras palabras, las • Suficiencia: En que grado el producto es completo.
personas dedicadas a V&V deben evaluar cuan bien el software está cumpliendo con
sus requisitos técnicos y sus objetivos de seguridad y confiabilidad relativos al sistema. • Rendimiento: En que grado el producto satisface los requisitos de rendimiento.
También asegura que los requisitos de usuario no están en conflicto con ninguno de los
estándares o requisitos aplicables a otros componentes del sistema. Las tareas de la Estos objetivos proveen un marco en que es posible determinar la aplicabilidad de
V&V de software son analizar, revisar, demostrar y testear todas las salidas del varios enfoques y técnicas de V&V.
desarrollo de software.
Actividades y metas
El proceso de V&V produce un Plan de Validación y Verificación de Software (PVVS),
planes individuales y reportes para tareas, reportes con resúmenes, reportes con A continuación se describen las principales metas y actividades del proceso de V&V de
anomalías y un reporte de validación y verificación de software (RVVS) al final. El software.
proceso de V&V contiene actividades de administración de V&V y actividades técnicas
de V&V de software. Actividades Metas
Administración de V&V de software El proceso requiere ser administrado y realizado en forma
Es necesario entender que el proceso de V&V tiene sus limitaciones. El objetivo central completa durante todo el proceso de desarrollo de software.
de los enfoques de V&V de software es el de asegurarse que el producto está libre de Planificación Planificar y mantener el proceso de V&V.
fallas y cumple con las expectativas de sus usuarios. Sin embargo, existen muchas Coordinación Coordinar e interpretar rendimiento y calidad del esfuerzo
del proceso de V&V.
limitaciones teóricas y prácticas que hacen que este objetivo no sea posible de obtener Reportar Reportar discrepancias a la brevedad posible al usuario o al
para el caso de muchos productos. Aunque no entraremos en detalles, estas grupo de desarrollo.
limitaciones se deben a: Monitoreo Identificar tempranamente caminos de problemas,
focalizando las tareas de V&V en ellos.
• Fundamentos teóricos. Evaluación de resultados Proveer una evaluación técnica del rendimiento del software
y sus atributos de calidad en cada revisión de software.
Evaluación del impacto del cambio Determinar el impacto completo de los cambios de software
• No resulta práctico probar todos los datos. propuestos.
Monitoreo del progreso técnico de V&V y Durante cada actividad de V&V, se debe revisar las tareas
• No resulta práctico probar todos los caminos posibles en el software. calidad de resultados planificadas de V&V, incluyendo nuevas para mantenerse
focalizado en las funciones críticas de rendimiento y calidad
del software.
• No es posible realizar una prueba de correctitud absoluta. Examinar documentación temprana del Muchas veces los llamados documentos conceptuales, para



proyecto verificar que el sistema que se construirá no es sólo posible,
pero que además utiliza las reglas, convenciones, algoritmos • Ingeniero de manutención: El ingeniero de V&V requiere realizar chequeos
y prácticas apropiadas al dominio de aplicación del sistema.
V&V de los requisitos de usuario Realizado para asegurarse que los requisitos de usuario
periódicos para asegurarse que la integridad del sistema se mantiene, que los
especificados son correctos, completos, consistentes, fieles, cambios que afectan su operación han sido documentados, y los operadores
legibles y es posible testearlos, y que además, satisfacerán han recibido entrenamiento en procedimientos nuevos o que han cambiado.
los requisitos de software.
V&V de los requisitos de software Realizado para asegurarse que los requisitos de software
especificados son correctos, completos, consistentes, fieles,
4.11 Documentador
legibles, es posible mapearlos desde los requisitos de
usuario y es posible testearlos, y que además, satisfacerán Durante el proceso de desarrollo de software, se genera una gran cantidad de
los requisitos de diseño. documentación. Dicha documentación debe ser almacenada en el repositorio del
V&V del diseño de software Provee seguridad de que los requisitos de software no son proyecto. La documentación sirve, entre otras cosas, para conocer la historia del
mal interpretados o implementados en forma incompleta.
proyecto. Hay que destacar que los documentos no se escriben al final del proyecto,
V&V del código Asegurarse que se utilicen los estándares en uso, que
usualmente consideran programación estructurada, reuso de sino que se van generando junto con las diferentes fases del proyecto. A medida que el
código, adopción de estándares y estilos de programación, proyecto va avanzando, los documentos deben ir siendo modificados para mantener el
etc. estado de los documentos a la par con el estado de desarrollo del proyecto. Por lo
Administración de tests Una actividad importante en la actividad de V&V es la de anterior, debe pensarse que los documentos van evolucionando, para mostrar el estado
asegurarse que se consideren y planifiquen todos los más reciente de desarrollo del proyecto. Sin embargo, el objetivo principal de la
testeos requeridos para el sistema.
V&V de la transferencia Asegurarse que se consideren todos los detalles de la
documentación es de actuar como medio de comunicación entre los miembros del
instalación y puesta en marcha del sistema, así como la equipo, incluyendo el cliente. Además, durante el proyecto, la documentación sirve
migración y/o poblamiento de sus datos y posibles también para reducir la distorsión de ideas, ayudar al control del proyecto, almacenar la
problemas de eficiencia que empiezan a aparecer. lógica de las decisiones tomadas y hacer visibles, en forma temprana, tanto las
V&V de la operación y manutención Cuando se realiza un cambio en el software, en necesario capacidades como las limitaciones del sistema.
repetir todas las actividades de V&V pertinentes para
asegurarse que nada queda fuera.
Se suele clasificar la documentación en dos categorías [Sommerville]:
• Documentación de procesos. Los documentos pertenecientes a esta categoría
El ingeniero a cargo del proceso de V&V de software debe interactuar con otros roles. registran la información del proceso de desarrollo y manutención del sistema. El
A continuación se detallan las interacciones más relevantes: objetivo de esta documentación es hacer “visible” el proceso de desarrollo,
manteniendo información sobre:
• Analista: El ingeniero de V&V tiene la responsabilidad de verificar que el analista
o Planificación y control de procesos (planes, calendarios, estimaciones).
especifica correctamente los requisitos de usuario y de software. Debe además,
verificar la documentación producida en diferentes fases del desarrollo del
o Reportes sobre recursos utilizados durante el desarrollo.
sistema.
o Estándares a ser utilizados en las diferentes fases.
• Diseñador: El ingeniero de V&V debe evaluar el nivel de concordancia entre los
requisitos de usuario y el modelo diseñado del sistema, buscando errores de
o Registro de ideas y estrategias a ser consideradas por el equipo.
interpretación en los requisitos, y características faltantes o mal concebidas.
o Lógica de las decisiones de diseño.
• Programador: El ingeniero de V&V debe verificar la correctitud del proceso de
traducción de diseño de software a su implementación en código. La verificación
o Detalles de la comunicación diaria entre los gerentes y el equipo de
de código es la última oportunidad de encontrar y eliminar errores pudiesen
desarrollo.
causar costos innecesarios y atrasos por realizar actividades de testeo sobre
código pobre.
• Documentación de producto. Estos documentos describen el desarrollo del
producto desde los puntos de vista técnico (documentación de sistema) y
• Téster: Se requiere coordinación con este rol en la ejecución de los casos de
usuario del sistema (documentación de usuario), siendo el usuario un usuario
tests, de acuerdo con las necesidades del cliente.



final o un usuario administrador del sistema. Estos dos tipos de documentación • Mantener la consistencia en la apariencia y estructura de los documentos,
tienen las siguientes características: facilitando su almacenamiento, recuperación e intercambio, no permitiendo el
almacenamiento de documentos con formatos diferentes.
o La documentación de sistema incluye los documentos desde la
especificación de requisitos hasta el plan de testeo de aceptación final. • Asegurarse que los cambios que necesitan hacerse en el sistema serán
Esta documentación es usada durante la fase de manutención y debe ser reflejados en la documentación correspondiente.
actualizada cada vez que se realizan cambios al sistema.
• Elaborar, almacenar y permitir la recuperación de las actas y registros
o La documentación de usuario debe contener una vista general de los generados durante las reuniones de revisión, los que constituyen parte del
servicios prestados por el sistema, como usarlo, un manual de referencia proceso de documentación.
que permita manejar los errores y facilidades prestadas por el sistema, un
documento que describa el proceso de instalación del sistema y un • Construir el manual de usuarios del sistema, MUS, que contempla los aspectos
manual de administración. de uso del sistema.

La calidad de la documentación generada es de gran importancia, debido a que la Actividades y metas
utilidad del sistema se degrada si no hay información adecuada de cómo usar o
entender sus características. Para obtener esta calidad, la documentación del proyecto Las actividades de un documentador también son muchas. A continuación se muestran
debe seguir estándares. Estándares que gobiernan el proceso, aseguran el intercambio algunas de ellas, ordenadas por metas.
satisfactorio de información, y determinan como será cada uno de los documentos.
Actividades Metas
Los estándares de desarrollo de documentos definen el proceso a seguir para producir El documentador debe diseñar y construir un Tener un repositorio central que permite
documentos de alta calidad. Estos estándares definen la forma de crear, de refinar y de repositorio de información compartido, donde se almacenar, recuperar y mantener la
realizar la producción final de los documentos. Es claro que estos estándares deben almacenará la documentación. documentación del proyecto.
Mantener el repositorio de información. El Tener accesible y organizada la última versión de
ser lo suficientemente flexibles como para permitir ser usados en distintos tipos de documentador debe agregar todos los nuevos todos los documentos generados durante el
documentos. documentos generados y remplazar los documentos proceso de desarrollo, en un repositorio común.
que fueron modificados en el proceso de desarrollo.
Además, es necesario considerar estándares que permitan el intercambio de Especificar el formato que será usado para elaborar
documentos en caso que se requieran ser intercambiados o transmitidos en forma la documentación. El formato especificado debe
contemplar al menos lo siguiente:
electrónica. El uso de estos estándares permiten la recreación del documento con el
• Estructura del documento.
mismo formato que el utilizado en el otro extremo. • Tipos de letra y colores a usar en cada Será posible integrar en un documento único
documento. general, todos los documentos almacenados en el
Por último, los estándares de documentos especifican la apariencia que todos los • Distribución de los elementos en el repositorio, sin necesidad de cambiar sus formatos
documentos deben tener. Dichos estándares tienen el propósito de mantener la documento (texto, imágenes, dibujos, logos, o estructura.
consistencia de los documentos, los que incluyen como identificarlo, su estructura y etc.).
• Características de las figuras, imágenes y
presentación, indicaciones para actualizarlo y líneas generales para un buen estilo de
dibujos consideradas en el documento.
escritura. Asegurarse que los documentos mantienen el Toda la información almacenada en el repositorio
estándar de documentación definido para el tendrá el formato definido, y se ajustará al estándar
Objetivos proyecto antes de incluirlos en el repositorio. de documentación en uso.
Durante las reuniones de revisiones, el Es necesario mantener la historia del proyecto en
El objetivo principal del rol de documentador es el de mantener la información generada documentador elaborará las actas de la reunión. el repositorio. Al término del proyecto, el repositorio
Estos documentos serán usados luego por el contendrá toda la información histórica del
durante el proceso de desarrollo. Como objetivos específicos se tienen los siguientes: ingeniero de validación y verificación. proyecto.
El usuario final debe disponer de un MUS, que le
• Permitir el almacenamiento y recuperación de la documentación de los procesos permita operar el sistema correctamente,
y productos más recientes durante el desarrollo, manteniendo así la información Elaborar el manual de uso del sistema, MUS. conociendo sus funciones, y administrando los
al día. errores que puedan aparecer durante su ejecución.



Metodología
• Administrador de configuración: El administrador de configuración y
La metodología de trabajo del documentador está enfocada a realizar las acciones que documentador comparten documentación a través del repositorio. Cuando se
le permita cumplir con sus objetivos principales y específicos. Al inicio, debe establecer autoriza un cambio de un documento, debe ser reflejado en el sistema de
los formatos usados en los documentos del proyecto, definiendo las estructuras de los administración de documentos. El propósito de esto es evitar inconsistencias y
documentos: permitir al equipo de desarrollo el acceso a la versión más reciente de cada
documento.
• Información de identificación de cada documento (nombre, tipo, autores, versión,
etc.). • Validación y verificación: El documentador mantiene una relación con el
ingeniero de V&V a través del registro elaborado durante las reuniones de
• Información que facilite la recuperación de la información (resúmenes, palabras revisión. Este registro, así como las minutas elaboradas son utilizadas durante el
claves). desarrollo de los planes y agendas de las reuniones de revisión.

• Enfoques para estructuras capítulos, secciones y subsecciones, y su • Asegurador de calidad: A los aseguradores de calidad se les ha confiado que
numeración respectiva. garanticen la calidad del producto a ser desarrollado. Toda la documentación del
proyecto es parte del producto. Por ello, parte del trabajo del asegurador de
• Índices y numeración de páginas. calidad es de garantizar la calidad de la documentación generada.

El estándar ESA define plantillas para cada uno de los documentos. En el Anexo XXX • Ingeniero de manutención: La documentación generada durante el desarrollo del
se encuentran dichas plantillas, las que deben ser utilizadas en caso de seguirse dicho producto es usado durante la fase de operación y manutención del sistema. Si
estándar. En caso de querer construir su propia metodología de documentación, se durante esta fase se realizan cambios, será necesario reflejarlos en la
sugiere revisar [Brockmann] y [Foehr et al.]. documentación correspondiente para mantener la consistencia de la
documentación con la operación del sistema.
Hay que señalar que no es poco frecuente encontrar gente que piensa que lo
importante de un documento es su contenido, menospreciando su forma. Es correcto Herramientas de apoyo
pensar que el contenido es vital. Sin embargo, se olvidan que un documento es un
instrumento de comunicación, y como tal, debe trabajarse su forma para no tener El documentador requerirá herramientas para la elaboración de documentos (minutas,
ambigüedades, inconsistencias, y malas interpretaciones. Lo anterior sugiere la documentos de acuerdos, manual de usuario) y herramientas de apoyo para la
necesidad de trabajar las formas del lenguaje con el propósito de producir documentos elaboración y administración del repositorio de documentos. Dentro del primer conjunto
con mayor capacidad comunicacional. Por otro lado, se hace vital cuidar la ortografía y de herramientas se encuentran las siguientes:
la gramática de todos los documentos del proyecto. En el Anexo XXX se incluyen
algunas sugerencias para esto. • Editor de texto, que permite elaborar documentos fácilmente y almacenarlos en
diferentes formatos, incluyendo HTML. Debe incluir una herramienta para el
Relación con otros roles chequeo ortográfico y de gramática.
• Navegador Web y editor HTML, que permita editar y publicar documentos
El rol de documentador está relacionado con los otros roles, debido a que el objetivo HTML, proveyendo diversas funciones.
principal de la documentación es el de servir como medio de comunicación entre los
miembros del equipo. El documentador recibe los documentos generados durante las Por otro lado, las herramientas de apoyo para la elaboración y administración del
diferentes fases, y se espera que los miembros del equipo puedan acceder a esta repositorio de documentos deben proveer el acceso a los documentos. Estas
documentación en el momento que quieran. herramientas dependerán de la decisión del repositorio en uso durante el desarrollo del
proyecto. Hoy en día existen muchas herramientas de manejo de repositorios de
Existe una relación estrecha con los otros roles, como se describe a continuación: documentos, con interfaces Web.

• Administrador de proyecto: La información del repositorio ayuda al administrador Perfil del documentador
a realizar los planes, agenda y presupuestos del proceso de desarrollo de
software.



El documentador debe ser una persona ordenada, con capacidades de mantener una
gran cantidad de información en forma ordenada y accesible. Todo el contenido de los o Elaborar el diseño lógico de la base de datos.
documentos debe ser organizado en forma clara. Esta claridad debe ser consecuencia
del formato en que se presenta la información. El documentador debe poseer o Construir el repositorio.
capacidades para no sólo apoyar su trabajo con tecnología, sino que además, deberá
diseñar y construir el repositorio para la documentación del proyecto. Esto incluye, al o Incluir un puntero entre la base de datos y el sitio Web del proyecto, en
menos, la definición del modelo de datos, definición de las interfaces, definición de los caso que sean diferentes.
perfiles de acceso de los usuarios, y la definición del protocolo social de uso de los
documentos. • Elaboración de las actas de reunión y documentos de acuerdo:

El documentador también debe tener creatividad para presentar la información y aptitud o Asistir a reuniones y escribir las actas.
de expresión para escribir. Hay que señalar que debe conocer y utilizar el procesador
de texto definido para el proyecto en toda su potencialidad, utilizando funcionalidades o Elaborar los documentos de acuerdo de las reuniones.
como estilos, corrector sintáctico y gramatical, y control de versión.
o Elaborar las actas finales de cada reunión.
Plan de trabajo
o Incluir las actas en el repositorio.
Las actividades del documentador se dividen en dos grupos. El primer grupo se refiere
a actividades que se realizan durante el ciclo de vida del proyecto. Entre estas • Almacenamiento de los documentos generados:
actividades se encuentra la elaboración de las actas de reuniones, el almacenamiento
de los documentos generados durante el proyecto, manutención del repositorio de o Verificar formato de los documentos.
información, y manutención del sitio Web del proyecto. El segundo grupo se refiere a
actividades que se realizan sólo una vez, al principio o al final del proyecto. Entre estas o Almacenar los documentos a medida que se van produciendo en el ciclo
actividades se encuentra la elaboración de la documentación, el diseño e de desarrollo.
implementación de la base de datos para la documentación, y la elaboración de los
perfiles de acceso a la documentación para cada uno de los miembros del equipo. • Manutención del repositorio con la documentación, actualizando la información a
medida que se produce.
A continuación se detallan las actividades principales del documentador:
• Manutención del sitio Web del proyecto durante todo su ciclo de vida.
• Elaboración de los formatos de la documentación:
• Elaboración del manual de usuario del sistema.
o Determinar los tipos de documentos que se desarrollarán durante el
proyecto. Es claro que parte de la labor del documentador se simplifica si el proyecto se ajusta a
un estándar de documentación, como es el caso del estándar ESA PS-05-0. En dicho
o Definir su formato (.doc, .rtf, .html, .txt, .ppt, .xls, .mpp, etc.). caso, las plantillas de documentos ya vienen definidas. En el Anexo XXX se muestran
dichas plantillas.
o Elaborar una plantilla para cada documento, en el formato definido.
Por otro lado, hoy en día se suele crear un sitio Web donde se maneja, en forma
o Publicar las plantillas. conjunta, la información pública y privada del proyecto. En ese sitio se mantiene el
repositorio de todos los documentos del proyecto. La información pública es toda
• Diseño y elaboración del repositorio central usado para almacenar información: aquella información del desarrollo del proyecto que se desee publicar con fines de
divulgación. En el caso privado, el acceso al repositorio está restringido a los miembros
o Análisis de las características deseadas del repositorio. del equipo de desarrollo. En el Capítulo 5 se muestra un ejemplo de la estructura y
funcionalidad de un sitio Web para administrar la documentación del proyecto.
o Estudio de las herramientas que serán usadas para elaborar el
repositorio.



4.12 Ingeniero de manutención Metodología

Hace ya casi 30 años, el proceso de manutención de software se caracterizaba con el La metodología a usar por el ingeniero de manutención debe considerar los siguientes
término “iceberg” [Canning], ya que los problemas que eran visibles eran una pequeña aspectos:
parte de la enorme cantidad de problemas potenciales y costos que se escondían
debajo de la superficie. • Establecer y coordinar la organización de manutención.

La manutención es la última fase del proceso de desarrollo de software. Sin embargo, • Definir los procesos de evaluación e información.
la manutención toma una parte importante del presupuesto destinado al desarrollo. En
general, dichos costos son subestimados o simplemente ignorados. Por otro lado, a • Definición de una secuencia estándar de eventos para cada requisito de
medida que se desarrollan más programas, la cantidad de esfuerzo y recursos manutención.
dedicados a la manutención crecerá. Al final, algunas empresas pueden llegar a
encontrarse con la barrera de la manutención, no pudiendo abordar nuevos proyectos • Establecer un sistema de registro e información de las actividades de
debido a que todos sus recursos están dedicados a mantener programas antiguos. manutención.

Sólo el 20% del trabajo de manutención es usado arreglando errores. El 80% restante • Definición de las actividades de revisión y evaluación.
se utiliza adaptando sistemas existentes a cambios en su ambiente externo, realizando
mejoras pedidas por usuarios, y realizando reingeniería del sistema para usos futuros. Relación con otros roles

Objetivos El ingeniero de manutención debe mantener relaciones con varios roles. Entre ellos se
consideran los siguientes:
Los objetivos a cumplir por un ingeniero de manutención son los siguientes:
• Administrador de proyecto. Debe supervisar y controlar los cambios requeridos,
• Modificar el software para adaptar nuevas funciones o modificar algunas utilizando los estándares del proyecto.
funciones existentes.
• Analista. Debido a que probablemente será necesario adaptar o perfeccionar el
• Modernizar el software por medio de cambios al sistema. sistema durante el tiempo, los analistas requerirán determinar nuevos requisitos.

• Asegurarse de que el equipo de desarrollo esté informado de los errores • Diseñador. Es necesario involucrar al diseñador para rediseñar las partes del
encontrados en el sistema. sistema que requieren ser corregidas, agregadas o perfeccionadas.

Actividades y metas • Programador. La naturaleza de las actividades requeridas para cubrir la fase de
manutención está estrechamente ligada con el rol de programador. Durante el
A continuación se presentan las actividades para cada una de las metas a cumplir por uso del sistema es probable que se detecten errores, siendo necesario
el ingeniero de manutención: comunicárselos al equipo de desarrollo para su reparación.
Actividades Metas • Téster. Debe testear las partes que han sido modificadas para chequear si están
Manutención correctiva Diagnóstico y corrección de errores encontrados durante el
uso del programa.
adecuadas para ser liberadas como parte del sistema.
Manutención adaptiva Adaptar el sistema a los cambios que pueden producirse en
el hardware, sistema operativo, periféricos y herramientas de • Asegurador de calidad. Es responsable de asegurar que el resultado del
trabajo. producto es de la calidad definida por el estándar en uso.
Manutención perfectiva Satisfacer la demanda de recomendaciones por parte de los
usuarios del sistema. Realizar cambios al sistema para
mejorar el proceso de manutención o confiabilidad del • Validación y verificación. Es responsable de revisar que el cliente quede
sistema. completamente satisfecho con el producto entregado.



• Documentador. Es responsable de documentar los cambios aprobados por el • Definición y uso de enfoques de revisión y evaluación.
Comité de Control de Cambios durante la fase de manutención.
4.13 Cliente comprometido
Herramientas de apoyo
Es frecuente escuchar que los términos “cliente”, “usuario” y “usuario final” se utilizan
El ingeniero de manutención debe utilizar para realizar su labor, una herramienta que le como sinónimos, lo cual puede provocar confusión. Un cliente es aquella persona
permita capturar requisitos de manutención, y además controlar la organización de la responsable de llevar a cabo el buen desempeño del proyecto, por parte de la empresa
manutención dentro del proyecto. Es deseable que dicha herramienta esté integrada al que contrata el desarrollo, también llamada mandante. El cliente debe representar los
ambiente de trabajo utilizado por el resto del equipo, compartiendo el mismo repositorio derechos y asumir los deberes de dicha empresa ante el equipo de desarrollo. Por lo
común. Todos los requisitos de manutención, así como la información operacional del tanto, el cliente debe estar presente en todas las fases del desarrollo del producto, y
proceso de manutención, deben ser almacenados en el sitio del proyecto para su realizar todas las actividades que se esperan de él, tales como la aceptación
revisión por todos los miembros del equipo de desarrollo. provisional y final del producto.

Perfil del ingeniero de manutención Por otro lado, los usuarios corresponden a las personas que están operando día a día
un sistema de software. Es la persona que conoce el problema, y utiliza la herramienta
El perfil del ingeniero de manutención, como es el caso de otras formas de computacional para apoyar su trabajo. Un cliente y un usuario no siempre son lo
administración, requiere de la creación y preservación de una atmósfera adecuada que mismo, ya que es posible que el cliente no opere el sistema de información.
permita llevar a cabo las actividades de la mejor forma posible. Existen aspectos que
son comunes a la mayoría de las actividades de administración. No obstante, se espera Un usuario final generalmente se refiere a aquella persona que utiliza el sistema, pero
que el ingeniero de manutención tenga visión para poder predecir las actividades de que es desconocida o no identificable. Generalmente pasa esto en sistemas de
manutención a futuro. información de uso masivo, tales como los sistemas de atención bancaria por Internet,
sistemas de apoyo al comercio electrónico, etc.
Plan de trabajo
En el desarrollo de software nos interesa tener clientes comprometidos. Es vital para el
Las actividades de manutención se llevan a cabo durante todo el proceso de desarrollo éxito del proyecto. Un cliente comprometido es aquel que participa en todas las etapas
del proyecto. Existen actividades en cada fase del proceso de desarrollo, desde del proyecto, compartiendo deberes y responsabilidades.
manutención preventiva a correctiva. El proceso de organización de la manutención
requiere trabajar con todo el equipo de desarrollo, organizando y controlando el buen Entre sus tareas están:
desempeño de sus actividades.
• Liderar el proyecto de software cuando la organización así lo requiere.
Algunas de las actividades a realizar por el ingeniero de manutención se describen a
continuación. • Debe conocer las distintas etapas y roles en la construcción de software.

• Planificación y coordinación de la organización de manutención durante el • Definir los objetivos del proyecto negociando con sus clientes las características
proyecto. que le afecten.

• Definición de procedimientos de evaluación e información. • Definir y priorizar requisitos.

• Desarrollo de herramientas para administrar los requisitos de manutención. • Revisar y aprobar documentos en forma responsable.

• Definición de una secuencia estándar de eventos para cada requisito de • Difundir el estado del proyecto al resto de su ámbito de trabajo.
manutención.
• Entregar los recursos necesarios para la realización del proyecto.
• Definición de un sistema de registro e información de las actividades de
manutención y organización de la manutención. • Escribir o participar en la elaboración del manual de usuario del sistema (MUS).


Apuntes de Taller de Ingeniería de Software

• Determinar y alertar del impacto del proyecto en otras áreas de la organización.

• Realizar la capacitación del sistema a sus usuarios.

• Construir el plan de pruebas de aceptación del sistema y aplicarlo al final del
proyecto, aceptando o rechazando la entrega.


Un cliente comprometido se relacionará principalmente con el administrador de
proyecto y con los analistas en forma frecuente. No obstante, también necesitará
relacionarse con otros roles con el propósito de controlar, monitorear y aceptar el
sistema. A continuación se detalla dichas relaciones:

• Administrador de proyecto. El cliente comprometido llevará toda la relación
formal del proyecto a través de su administrador. En otras palabras, toda la
comunicación formal entre las dos partes del proyecto se hace a través de estas
dos personas. El cliente deberá además, cuidar la relación con el equipo de
desarrollo.

• Analista. El cliente comprometido participará en reuniones sistemáticas de
análisis, dirigidas por los analistas. Deberá además participar en las RTFs de
análisis, tales como las fases de revisión RU/R y RS/R.

• Diseñador: El cliente comprometido debe participar en las fases de revisión
DA/R y DD/R junto a los diseñadores.

• Programador. El cliente comprometido debe participar en la fase de revisión
DD/R junto a los programadores.

• Téster. El cliente debe preparar el plan de aceptación parcial y plan de
aceptación definitiva, con apoyo del téster. Además, deberá trabajar con el téster
para apoyar la construcción del plan de testeo.

• Asegurador de calidad. El cliente comprometido debe apoyar al asegurador de
calidad en su búsqueda de diferencias entre los requisitos de usuario y las
funcionalidades implementadas en el sistema.

© 2003 David Fuller Padilla 51

Roles desarrollo software

Más contenido relacionado

La actualidad más candente (18)

Similar a Roles desarrollo software (20)

Más de Isabel (20)

Roles desarrollo software