Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Roles Desarrollo Software
Roles Desarrollo Software
4.1
Introduccin
Es bastante comn que, frente a una oferta de una empresa en busca de personal
calificado para su equipo de desarrollo de software, nos sintamos atrados a postular a
un rol especfico. Por ello, al final del captulo se entrega, adicionalmente, algunas
recomendaciones bsicas para postular al cargo que se desee.
4.2
La fbula de la granja
Un da cualquiera, los animales de una granja decidieron hacer una fiesta, con el
propsito de pasar un momento agradable. Para organizar la fiesta, se reunieron el
mismo da en la maana. Cada animal deba llevar algo a la fiesta. Como es lgico, a la
vaca le pidieron la leche. A la gallina, le toc llevar los huevos. Y al chancho, el tocino.
En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el chancho se
encuentra involucrado. Su participacin le obliga a entregar parte de si mismo como
aporte para la fiesta. Al chancho le toca aportar una cuota de sacrificio mayor. Lo
anterior muestra la diferencia entre participar en un evento y estar involucrado.
Tomemos esta fbula para caracterizar a los miembros del grupo de un desarrollo de
software. Cmo se comportan, en general? Participan o estn comprometidos en el
proceso de desarrollo de software?
Parece claro que lo deseable, desde el punto de vista del problema completo, es tener
integrantes comprometidos. Pero, cmo se obtienen estos miembros comprometidos?
Es posible crear miembros del grupo comprometidos? Administrador de proyecto
comprometido, analista comprometido, diseador comprometido, programador
comprometido, tster comprometido, asegurador de calidad comprometido,
documentador comprometido, ingeniero de manutencin comprometido, ingeniero de
validacin y verificacin comprometido, administrador de la configuracin
comprometido y cliente comprometido?
La fbula anterior nos ensea la diferencia entre participar y estar comprometidos en
una actividad. Es claro que para tener miembros del equipo de desarrollo
comprometidos, es necesario capacitarlos en sus deberes y derechos en el ciclo de
vida del desarrollo de software.
Es muy poco probable que un miembro no capacitado pueda estar comprometido con
los objetivos del proyecto. Este presentar claras deficiencias en el momento de
participar en el proceso. Como ejemplo, se mencionan algunas:
1.
2.
3.
4.3
Administrador de proyecto
Una de las preocupaciones principales para los administradores debe ser el tener una
visin y misin claras del proyecto, trabajando para que ambas se cumplan. En otras
palabras, el foco de un administrador de proyecto debe estar en el bosque ms que en
los rboles. Sin embargo, debe cuidar cada rbol ya que cada uno de ellos contribuye
al bosque.
El rol de administrador de proyecto es un rol muy importante, debido a que sus
acciones y decisiones afectan al proyecto completo.
Objetivos
Algunos de los objetivos de un administrador de proyecto son los siguientes:
1.
2.
3.
Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus
integrantes a cumplir sus objetivos particulares. Al final, se cumplir el
objetivo general.
4.
5.
Algunos de los objetivos especficos a cumplir por un administrador de proyecto son los
siguientes:
1.
2.
3.
En general:
Actividades y metas
A continuacin se muestra el conjunto de actividades a realizar por el administrador de
proyecto para lograr cumplir con xito las metas definidas.
Actividades
Desarrollo eficiente de reuniones:
Visin.
Misin.
Metas.
Objetivos.
Actividades.
El administrador deber tener una comunicacin fluida con cada miembro del equipo
para analizar problemas particulares, y si es necesario, tomar acciones correctivas. En
particular, el administrador de proyecto deber apoyar de la siguiente forma a cada rol:
Analistas: Trabajar con los analistas para estudiar las necesidades de los
clientes y los requisitos del sistema.
Tsters: Trabajar con ellos para determinar que tipo de testeo deber utilizarse,
y con que profundidad, de acuerdo con los requisitos de seguridad en el diseo
del sistema y de los recursos disponibles. Los resultados de los tests ayudan a
determinar el xito del proyecto, preocupacin principal de la administracin de
proyecto.
Administracin:
Entregar un plan de trabajo general basado en diagramas
Gantt y de flujo de actividades, apoyado con el plan de
trabajo de cada rol.
El plan de trabajo general deber contener estimaciones de
horas-hombre de cada actividad, que permita estimar los
Coordine todas las actividades.
recursos humanos requeridos.
Desarrollar el contrato junto con el cliente.
Realizar actividades de organizacin, direccin y control.
Trabajar con los analistas para estudiar las necesidades de
los clientes y los requisitos del sistema.
Metas
Herramientas de trabajo
El administrador de proyecto deber utilizar herramientas que apoyen su trabajo.
Algunas de estas herramientas se describen a continuacin:
Herramientas de comunicacin, tales como telfono fijo y mvil, que permita ser
localizado y localizar rpidamente a otros miembros del equipo. El correo
electrnico y grupos de discusin tambin son herramientas de uso frecuente.
Herramientas de administracin de proyectos, que permitan definir y modificar
diagramas Gantt y de flujo de actividades. Ejemplos de esto son MS Project
2000 y MS Project Central, y Primavera.
Herramientas que permitan contabilizar el uso de recursos, tal como una planilla
de clculos. Ejemplo de esto es MS Excel.
Grabadora de audio.
Grabadora de video.
Perfil de un administrador de proyecto
Escuchar y comunicar.
4.4
Analistas
Actividades
Entrevistar al cliente, ayudndole a identificar sus
necesidades.
Metas
Determinar las necesidades esenciales y no
esenciales, as como las que son de segundo
nivel.
Impedir la introduccin de defectos
tempranamente en la construccin del sistema.
10
a que es muy difcil tener una herramienta que detecte las necesidades del cliente. Este
trabajo est ms bien relacionado con el criterio de los analistas. Estas herramientas
administran los requisitos, sus propiedades, y sus cambios.
Por otro lado, existen herramientas que apoyan a los analistas en tareas
administrativas y en el manejo de reuniones. Algunos ejemplos de esto son:
Proyectores de diapositivas.
Videograbadoras.
Grabadoras de audio.
Diseador: Los diseadores deben interactuar con los analistas para determinar
la factibilidad del proyecto, y establecer los objetivos del sistema para un buen
diseo. Los analistas deben permanecer en contacto estrecho con los
diseadores debido a que utilizarn la arquitectura del sistema. Los diseadores
deben poder ayudarle a los analistas.
Los analistas deben conocer y manejar perfectamente los mtodos y las tecnologas de
apoyo para realizar las fases de anlisis. Adems, se espera creatividad, lo que le
permitir establecer diferentes alternativas de modelos para la arquitectura del sistema
a construir.
Tster: Los analistas participan junto con los tsters en la revisin de los
documentos de anlisis de requisitos.
Asegurador de calidad: Debe revisar los documentos hechos por los analistas.
Resulta innecesario enumerar las herramientas disponibles para apoyar las fases de
anlisis, debido a que hay muy pocas, las que no son de mucha utilidad. Esto, debido
11
Perfil de un analista
Tambin es importante que los analistas estn muy familiarizados con las tcnicas de
diseo que se utilizarn en las siguientes fases. Adems, se hace necesario que est
familiarizado con los diferentes lenguajes de programacin para ayudar a escoger el
apropiado para la construccin del sistema.
Plan de trabajo
A continuacin se menciona algunas de las actividades a realizar por los analistas, las
que forman parte de su plan de trabajo.
12
4.5
Diseadores
13
Actividades y metas
A continuacin se describe las actividades y metas a considerar por un diseador.
Actividades
Descomposicin de subsistemas
Definir la administracin de acceso a
recursos globales
Seleccionar una tcnica de administracin
Metas
Crear una estructura interna del sistema, llamada una
arquitectura y la definicin de relaciones entre subsistemas.
Seleccionar las polticas apropiadas para nombres lgicos,
espacio, unidades fsicas, y acceso a datos compartidos.
Seleccionar el mtodo de almacenamiento apropiado para
14
de almacenamiento de datos
Interactuar con los programadores
Asignacin de subsistemas a
procesadores
Administracin de la concurrencia
Seleccin de estrategias de control
Administracin de condiciones de borde
Metodologas de diseo
Existen muchas metodologas de diseo. Describiremos brevemente slo una clase de
ellas, llamado mtodos de descomposicin. El diseo de un sistema de software
implica la descomposicin del sistema en partes de menor tamao, cada una de las
cuales puede refinarse en forma independiente. Dentro de los mtodos de
descomposicin, mencionaremos los siguientes dos:
15
Tster: Los diseadores deben coordinar esfuerzos con los tsters para
asegurar que el diseo arquitectnico del sistema de software incluye
especificaciones que ayuden en el ejercicio de casos de testeo. Adems, debe
apoyar a los tsters en la verificacin de requisitos.
16
Plan de trabajo
El plan de trabajo de los diseadores incluye las siguientes actividades para el diseo
del sistema.
4.6
Programadores
17
18
Metas
Determinar los lenguajes posibles de usar e
identificar las posibles herramientas de desarrollo
Seleccionar el ambiente apropiado
Seleccionar el lenguaje apropiado
Seleccionar el lenguaje apropiado y lenguaje de
programacin
19
20
Tster: El programador debe interactuar con el tster para determinar una forma
apropiada de construir los tests y de testear los programas. El programador debe
estar presente durante el testeo de cdigo, cuando situaciones no esperadas
suceden o es necesario realizar pequeas modificaciones al cdigo.
Las reuniones que se realizan son de carcter informativo para determinar el estatus de
la codificacin.
Relacin con otros roles
Los programadores deben relacionarse con otros miembros del grupo del proyecto.
Dentro de stos, se encuentran los siguientes:
21
Herramientas de apoyo
Existen muchas herramientas para ayudar al programador a desarrollar el sistema.
stas consisten principalmente en ambientes de desarrollo integrados adaptados para
un lenguaje de programacin. Estos ambientes pueden compilar y ejecutar un
programa usando comandos para ello. La mayora de estos ambientes tambin
proveen herramientas para depurar el programa. Algunos ambientes tambin proveen
herramientas de scheduling.
Perfil de un programador
El perfil del programador requiere conocimiento en varios ambientes, pudiendo
ayudarle a los analistas y diseadores a elegir el apropiado. Debe tener experiencia en
el desarrollo de aplicaciones en el ambiente seleccionado.
22
Codificar y depurar.
Testear.
Demostrar que las funciones del sistema parecen estar funcionando de acuerdo
a sus especificaciones.
4.7
Objetivos
Actividades y metas
Tster
Actividades
23
Metas
24
Los tests de caja blanca son realizados tempranamente en el ciclo de vida del
desarrollo. Los tests de caja negra se utilizan en etapas ms tardas del ciclo. Debido a
que la metodologa de caja negra ignora las estructuras de control del programa, la
atencin se focaliza en el dominio de la informacin.
Metodologa
Los tsters deben utilizar una metodologa que en forma sistemtica, organizada y
estructurada, les permita detectar y corregir, los errores y defectos introducidos en el
proceso de desarrollo del sistema. Tpicamente, se utilizan dos tcnicas para ello: el
test de la caja blanca y el test de la caja negra.
Los tests de caja blanca corresponden a un mtodo de diseo de casos de tests que
utilizan la estructura de control del diseo procedural para derivar los casos de tests.
Usando este mtodo, el tster puede derivar casos de tests para lo siguiente:
Ejecutar todos los loops en sus lmites y sobre sus lmites operacionales.
Por otro lado, los tests de caja negra se focalizan en los requisitos de usuario del
sistema. De esa forma, este tipo de tests permite que los tsters generen conjuntos de
datos de entrada que ejercitarn completamente los requisitos del sistema. Los tests de
caja negra no son una alternativa a los tests de caja blanca. Ms an, corresponde a
un enfoque complementario que posiblemente descubra una clase diferente de errores.
Los tests de caja negra tratan de encontrar errores en las siguientes categoras:
Errores de interfaces.
25
Perfil de un tster
El perfil de un tster debe considerar las siguientes caractersticas:
26
Debe adems tener una personalidad alegre, debido a que debe relacionarse
con gran parte de los miembros del equipo de desarrollo.
Actividades
Revisar los documentos de requisitos de
usuario y de software
Plan de trabajo
El plan de trabajo del tster debe incluir, al menos, las siguientes actividades:
Coordinarse con los diseadores para incluir el test del diseo en el documento.
4.8
Metas
Asegurarse que la especificacin de requisitos es una
representacin correcta y completa de las expectativas del
cliente, y que es suficientemente clara para el equipo de
desarrollo, especialmente para los diseadores.
Asegurarse que el plan es creado y se cumple.
Asegurarse que el plan se crea, que es adecuado al
proyecto especfico, y que se sigue en cada fase del ciclo
hasta que se entrega el producto.
Asegurarse que los diseadores seleccionaron la
metodologa apropiada y que el producto final cumple con
los requisitos de rendimiento, diseo y verificacin.
Asegurarse que el software producido cumple con los
requisitos especificados y con los atributos de calidad
impuestos.
Asegurarse que se realizan monitoreos de errores en cada
fase del desarrollo y que se respaldan las lneas bases
haciendo que el producto no se pueda perder.
Asegurarse que la documentacin cumple con el estndar
utilizado durante el desarrollo del producto de software.
Metodologa
Aseguradores de calidad
Los participantes de una RTF son el productor (la persona que desarroll el producto a
revisar), un encargado de la revisin que evala el producto genera copias de material,
27
28
y lo distribuye a dos o tres revisores para que se preparen de antemano. Uno de los
revisores toma el rol de documentador de los aspectos ms relevantes aparecidos
durante la revisin.
El asegurador de calidad debe ser una persona con mucha experiencia en proyectos
de desarrollo de software, con conocimientos suficientes sobre tcnicas que aseguren
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 revisin, los participantes deben decidir si: 1. aceptar el producto sin
modificacin posterior; 2. rechazar el producto debido a errores serios; o 3. aceptar el
producto con errores menores que deben ser corregidos, pero no se requiere una
revisin posterior.
Plan de trabajo
El plan de trabajo de un asegurador de calidad es extenso, ya que debe estar
involucrado en todas las fases del desarrollo del software.
4.9
A continuacin se analiza la relacin del asegurador de calidad con los otros roles:
Administrador de configuracin
29
30
Cul es mi estatus?
31
32
Objetivos
El objetivo principal de la administracin de configuracin de software es la
administracin efectiva del ciclo de vida del sistema de software y la evolucin de su
configuracin. En otras palabras, corresponde al establecimiento y manutencin de los
productos de software del proyecto a travs del ciclo de vida del software. La
administracin de configuracin no es una tarea independiente, existe para apoyar el
desarrollo y manutencin del producto de software. Es necesario utilizar el criterio al
aplicar tcnicas de administracin de configuracin. Por un lado, muy poca
administracin de la configuracin y es posible perder productos, necesitando trabajo
adicional para rehacerlos. Por otro lado, mucha administracin de la configuracin y la
organizacin nunca producir un producto, debido a que estar muy ocupada moviendo
papeles.
Metodologa
Actividades y metas
Actividades
Preparar el Plan de Administracin de la Configuracin
de Software de acuerdo al estndar en uso
lneas bases.
Si uno de los eventos anteriores ocurre, estas personas deben realizar las actividades
correspondientes de acuerdo al Plan de Administracin de Configuracin de Software.
Adems, deben saber que la administracin de la configuracin de software es un
punto central en cualquiera de esas actividades.
Especficamente, la relacin con cada uno de los roles es:
33
34
Analista: Los tems de configuracin de software producidos por este rol son el
DRU y el DRS.
Diseador: Los tems de configuracin de software producidos por este rol son el
DDA y el DDD. Por lo tanto, el diseador es parte del CCC.
Una vez que el proyecto empiece, debe realizar las cinco actividades principales
durante el ciclo de vida del software:
35
36
Fundamentos tericos.
37
Objetivos
El objetivo principal del proceso de V&V de software es el de analizar y testear en
forma completa el software durante el desarrollo para determinar que ejecuta su
funcionalidad correctamente, asegurarse que no ejecuta funciones no intencionalmente
definidas y proveer informacin sobre su calidad y confiabilidad.
Dependiendo de las actividades de V&V respecto a la funcionalidad y rendimiento del
software, es posible identificar algunos objetivos:
Metas
El proceso requiere ser administrado y realizado en forma
completa durante todo el proceso de desarrollo de software.
Planificacin
Planificar y mantener el proceso de V&V.
Coordinacin
Coordinar e interpretar rendimiento y calidad del esfuerzo
del proceso de V&V.
Reportar
Reportar discrepancias a la brevedad posible al usuario o al
grupo de desarrollo.
Monitoreo
Identificar tempranamente caminos de problemas,
focalizando las tareas de V&V en ellos.
Evaluacin de resultados
Proveer una evaluacin tcnica del rendimiento del software
y sus atributos de calidad en cada revisin de software.
Evaluacin del impacto del cambio
Determinar el impacto completo de los cambios de software
propuestos.
Monitoreo del progreso tcnico de V&V y Durante cada actividad de V&V, se debe revisar las tareas
calidad de resultados
planificadas de V&V, incluyendo nuevas para mantenerse
focalizado en las funciones crticas de rendimiento y calidad
del software.
Examinar documentacin temprana del Muchas veces los llamados documentos conceptuales, para
38
proyecto
V&V de los requisitos de usuario
Administracin de tests
V&V de la transferencia
4.11 Documentador
Durante el proceso de desarrollo de software, se genera una gran cantidad de
documentacin. Dicha documentacin debe ser almacenada en el repositorio del
proyecto. La documentacin sirve, entre otras cosas, para conocer la historia del
proyecto. Hay que destacar que los documentos no se escriben al final del proyecto,
sino que se van generando junto con las diferentes fases del proyecto. A medida que el
proyecto va avanzando, los documentos deben ir siendo modificados para mantener el
estado de los documentos a la par con el estado de desarrollo del proyecto. Por lo
anterior, debe pensarse que los documentos van evolucionando, para mostrar el estado
ms reciente de desarrollo del proyecto. Sin embargo, el objetivo principal de la
documentacin es de actuar como medio de comunicacin entre los miembros del
equipo, incluyendo el cliente. Adems, durante el proyecto, la documentacin sirve
tambin para reducir la distorsin de ideas, ayudar al control del proyecto, almacenar la
lgica de las decisiones tomadas y hacer visibles, en forma temprana, tanto las
capacidades como las limitaciones del sistema.
Se suele clasificar la documentacin en dos categoras [Sommerville]:
El ingeniero a cargo del proceso de V&V de software debe interactuar con otros roles.
A continuacin se detallan las interacciones ms relevantes:
39
40
41
Construir el manual de usuarios del sistema, MUS, que contempla los aspectos
de uso del sistema.
Actividades y metas
Metas
Tener un repositorio central que permite
almacenar,
recuperar
y
mantener
la
documentacin del proyecto.
Tener accesible y organizada la ltima versin de
todos los documentos generados durante el
proceso de desarrollo, en un repositorio comn.
42
Metodologa
La metodologa de trabajo del documentador est enfocada a realizar las acciones que
le permita cumplir con sus objetivos principales y especficos. Al inicio, debe establecer
los formatos usados en los documentos del proyecto, definiendo las estructuras de los
documentos:
El estndar ESA define plantillas para cada uno de los documentos. En el Anexo XXX
se encuentran dichas plantillas, las que deben ser utilizadas en caso de seguirse dicho
estndar. En caso de querer construir su propia metodologa de documentacin, se
sugiere revisar [Brockmann] y [Foehr et al.].
Hay que sealar que no es poco frecuente encontrar gente que piensa que lo
importante de un documento es su contenido, menospreciando su forma. Es correcto
pensar que el contenido es vital. Sin embargo, se olvidan que un documento es un
instrumento de comunicacin, y como tal, debe trabajarse su forma para no tener
ambigedades, inconsistencias, y malas interpretaciones. Lo anterior sugiere la
necesidad de trabajar las formas del lenguaje con el propsito de producir documentos
con mayor capacidad comunicacional. Por otro lado, se hace vital cuidar la ortografa y
la gramtica de todos los documentos del proyecto. En el Anexo XXX se incluyen
algunas sugerencias para esto.
43
Por otro lado, las herramientas de apoyo para la elaboracin y administracin del
repositorio de documentos deben proveer el acceso a los documentos. Estas
herramientas dependern de la decisin del repositorio en uso durante el desarrollo del
proyecto. Hoy en da existen muchas herramientas de manejo de repositorios de
documentos, con interfaces Web.
Perfil del documentador
44
El documentador debe ser una persona ordenada, con capacidades de mantener una
gran cantidad de informacin en forma ordenada y accesible. Todo el contenido de los
documentos debe ser organizado en forma clara. Esta claridad debe ser consecuencia
del formato en que se presenta la informacin. El documentador debe poseer
capacidades para no slo apoyar su trabajo con tecnologa, sino que adems, deber
disear y construir el repositorio para la documentacin del proyecto. Esto incluye, al
menos, la definicin del modelo de datos, definicin de las interfaces, definicin de los
perfiles de acceso de los usuarios, y la definicin del protocolo social de uso de los
documentos.
Plan de trabajo
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
actividades se encuentra la elaboracin de las actas de reuniones, el almacenamiento
de los documentos generados durante el proyecto, manutencin del repositorio de
informacin, y manutencin del sitio Web del proyecto. El segundo grupo se refiere a
actividades que se realizan slo una vez, al principio o al final del proyecto. Entre estas
actividades se encuentra la elaboracin de la documentacin, el diseo e
implementacin de la base de datos para la documentacin, y la elaboracin de los
perfiles de acceso a la documentacin para cada uno de los miembros del equipo.
45
Manutencin del sitio Web del proyecto durante todo su ciclo de vida.
46
Metodologa
Slo el 20% del trabajo de manutencin es usado arreglando errores. El 80% restante
se utiliza adaptando sistemas existentes a cambios en su ambiente externo, realizando
mejoras pedidas por usuarios, y realizando reingeniera del sistema para usos futuros.
Objetivos
Actividades y metas
Tster. Debe testear las partes que han sido modificadas para chequear si estn
adecuadas para ser liberadas como parte del sistema.
A continuacin se presentan las actividades para cada una de las metas a cumplir por
el ingeniero de manutencin:
Actividades
Manutencin correctiva
Manutencin adaptiva
Manutencin perfectiva
Metas
Diagnstico y correccin de errores encontrados durante el
uso del programa.
Adaptar el sistema a los cambios que pueden producirse en
el hardware, sistema operativo, perifricos y herramientas de
trabajo.
Satisfacer la demanda de recomendaciones por parte de los
usuarios del sistema. Realizar cambios al sistema para
mejorar el proceso de manutencin o confiabilidad del
sistema.
47
48
Herramientas de apoyo
El ingeniero de manutencin debe utilizar para realizar su labor, una herramienta que le
permita capturar requisitos de manutencin, y adems controlar la organizacin de la
manutencin dentro del proyecto. Es deseable que dicha herramienta est integrada al
ambiente de trabajo utilizado por el resto del equipo, compartiendo el mismo repositorio
comn. Todos los requisitos de manutencin, as como la informacin operacional del
proceso de manutencin, deben ser almacenados en el sitio del proyecto para su
revisin por todos los miembros del equipo de desarrollo.
Perfil del ingeniero de manutencin
El perfil del ingeniero de manutencin, como es el caso de otras formas de
administracin, requiere de la creacin y preservacin de una atmsfera adecuada que
permita llevar a cabo las actividades de la mejor forma posible. Existen aspectos que
son comunes a la mayora de las actividades de administracin. No obstante, se espera
que el ingeniero de manutencin tenga visin para poder predecir las actividades de
manutencin a futuro.
Plan de trabajo
Las actividades de manutencin se llevan a cabo durante todo el proceso de desarrollo
del proyecto. Existen actividades en cada fase del proceso de desarrollo, desde
manutencin preventiva a correctiva. El proceso de organizacin de la manutencin
requiere trabajar con todo el equipo de desarrollo, organizando y controlando el buen
desempeo de sus actividades.
Algunas de las actividades a realizar por el ingeniero de manutencin se describen a
continuacin.
Es frecuente escuchar que los trminos cliente, usuario y usuario final se utilizan
como sinnimos, lo cual puede provocar confusin. Un cliente es aquella persona
responsable de llevar a cabo el buen desempeo del proyecto, por parte de la empresa
que contrata el desarrollo, tambin llamada mandante. El cliente debe representar los
derechos y asumir los deberes de dicha empresa ante el equipo de desarrollo. Por lo
tanto, el cliente debe estar presente en todas las fases del desarrollo del producto, y
realizar todas las actividades que se esperan de l, tales como la aceptacin
provisional y final del producto.
Por otro lado, los usuarios corresponden a las personas que estn operando da a da
un sistema de software. Es la persona que conoce el problema, y utiliza la herramienta
computacional para apoyar su trabajo. Un cliente y un usuario no siempre son lo
mismo, ya que es posible que el cliente no opere el sistema de informacin.
Un usuario final generalmente se refiere a aquella persona que utiliza el sistema, pero
que es desconocida o no identificable. Generalmente pasa esto en sistemas de
informacin de uso masivo, tales como los sistemas de atencin bancaria por Internet,
sistemas de apoyo al comercio electrnico, etc.
En el desarrollo de software nos interesa tener clientes comprometidos. Es vital para el
xito del proyecto. Un cliente comprometido es aquel que participa en todas las etapas
del proyecto, compartiendo deberes y responsabilidades.
Entre sus tareas estn:
Definir los objetivos del proyecto negociando con sus clientes las caractersticas
que le afecten.
49
50
51