Documentos de Académico
Documentos de Profesional
Documentos de Cultura
RESPONSABILIDADE
S DE UN EQUIPO DE
DESARROLLO DE
SOFTWARE
INTRODUCCION
El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse
en grupo. Adems, esta actividad requiere de distintas capacidades, las que no se encuentran todas
en una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que
cubran todas las capacidades requeridas. Cada una de esas personas aportar al grupo parte del
total de las capacidades necesarias para llevar a cabo con xito el desarrollo
Por ello, es que cada persona debe tener un rol dentro del grupo, que viene dado por su experiencia
y capacidades personales. En este captulo se describen los roles que tradicionalmente
se
consideran en el desarrollo de software. Estos roles son administrador de proyecto,
analista, diseador, programador, tster, asegurador de calidad, documentador, ingeniero de
manutencin,
ingeniero de validacin y verificacin, administrador de la configuracin y por
ltimo, el cliente. Para cada uno de estos roles, se definen sus objetivos, actividades,
interaccin con otros roles, herramientas a utilizar, perfil de las personas en ese rol y un plan de
trabajo.
Administrador de
proyecto
Es la persona que administra y controla los recursos asignados a un
proyecto, con el propsito de que se cumplan correctamente los planes
definidos.
Por ello debe estar en el control y coordinacin de los diferentes
eventos y actividades de un proyecto.
los recursos asignados pueden ser recursos humanos, econmicos,
tecnolgicos, etc.
OBJETIVOS
*Analistas
*Diseadores
*Testers
*Aseguradores de calidad
*Ing. manutencin
*Documentadores
*Clientes
Plan de trabajo
Analista
Tster: Los analistas participan junto con los tsters en la revisin de los documentos de anlisis
de requisitos.
Asegurador de calidad: Debe revisar los documentos hechos por los analistas.
Administrador de la configuracin: Debe pedir los cambios pertinentes, evitando errores a futuro.
Documentador: Los analistas debern entregarles la informacin que servir para la documentacin
del sistema.
Debe ser una persona sociable, expresando sus ideas en forma clara en un
lenguaje comn con el cliente.
Plan de trabajo
Plan de trabajo
Diseadores
Es el encargado de generar el diseo del sistema.
Generar el diseo arquitectnico y diseo detallado del
sistema, basndose en los requisitos.
Generar prototipos rpidos del sistema (con analistas y
programadores) para chequear los requisitos.
Generar el documento de diseo arquitectnico de
software (DDA), y mantenerlo actualizado durante el
proyecto.
Velar porque el producto final se ajuste al diseo realizado
(funciones de tster).
Objetivos
crear una estructura interna limpia y relativamente simple, tambin llamada a veces una
arquitectura. Un diseo es el producto final del proceso de diseo.
Perfil de un diseador
mostrar
Generalmente
Deben
Deben
Plan de trabajo
Organizar
Asignar
el sistema en subsistemas.
Seleccionar
un administrador de datos.
Identificar
Elegir
Considerar
condiciones de borde
PROGRAMADORES
PROGRAMADORES
OBJETIVOS
Menor cantidad de problemas de testeo.
Aumento de la productividad de los programadores.
Aumento de la eficiencia en la manutencin del programa.
Aumento de la eficiencia en la modificacin del programa.
PROGRAMADORES
PERFIL DEL PROGRAMADOR
Debe conocer diferentes lenguajes de programacin disponibles para el
ambiente seleccionado, y debe tener experiencia en el lenguaje de
programacin seleccionado. Es preferible que el programador tenga
conocimientos en diferentes paradigmas de programacin y estilos.
Los
Tester
El tster es el encargado de asegurar la calidad de cada uno de los productos sujeto que apoye el
proceso de deteccin y eliminacin de los errores y defectos del sistema en construccin,
(documentos, prototipos, etc). Entre sus tareas estn:
Construir y aplicar los planes de prueba unitarios, de mdulo, de sistema, y aceptacin parcial,
mantenindolos actualizados durante el proyecto.
Velar por la completitud, y exactitud (no ambigedades) de todos los documentos del proyecto.
Coordinar las inspecciones, y/o caminatas.
Velar por la adhesin al estndar adoptado para el desarrollo.
Velar por la calidad del producto final (cumplimiento de los requisitos).
Actividades y metas
Actividades
Metas
Participacin
en
el Prevenir errores en las
proceso de especificacin etapas tempranas del
del sistema
desarrollo
Interaccin
diseador
con
Metodologas
Se utilizan dos tcnicas:
Los tests de caja blanca corresponden a un mtodo
de diseo de casos de tests que utilizan
la estructura
de control del diseo procedural para derivar
los casos de
tests. Usando este mtodo, el tster
puede derivar casos de tests para lo siguiente:
Asegurarse que todos las trayectorias independientes en un mdulo han sido visitadas al menos una
vez.
Ejercitar todas las decisiones lgicas en sus lados verdadero y falso.
Ejecutar todos los loops en sus lmites y sobre sus lmites operacionales.
Ejercitar estructuras de datos internas para asegurar su validez.
Metodologas
Los tests de caja negra se focalizan en los requisitos
de usuario del sistema. De esa
forma, este tipo de
tests permite que los tsters generen conjuntos
de datos de entrada que ejercitarn completamente
los requisitos
del sistema. Los tests de caja negra no son una alternativa a los tests de caja blanca. Ms an, corresponde
a un enfoque complementario que posiblemente descubra una clase diferente de errores.
Los tests de caja negra tratan de encontrar errores en las siguientes categoras:
Funciones incorrectas o faltantes.
Errores de interfaces.
Errores en estructuras de datos o acceso a bases de datos externas.
Errores de rendimiento del sistema y errores de inicializacin y terminacin.
Perfil de un tester
Ser un buen programador en el lenguaje seleccionado, y tener experiencia en el
desarrollo de sistemas.
Conocer bien la metodologa de diseo utilizada.
Ser sistemtico en las revisiones de cdigo y resultados de los tests.
Tener una personalidad agresiva para buscar errores en el cdigo y documentos
del proyecto.
Debe adems tener una personalidad alegre, debido a que debe relacionarse con
gran parte de los miembros del equipo de
desarrollo.
Documentador
La documentacin sirve, entre
otras cosas, para conocer la
historia del proyecto. Hay que
destacar que los documentos
no se escriben al final del
proyecto, sino que se van
generando junto con las
diferentes fases del proyecto.
SE CLASIFICAN EN DOS
1.- Documentacin de procesos: Los documentos
pertenecientes a esta categora registran la
informacin del proceso de desarrollo y manutencin
del sistema.
Planificacin
Objetivos
Cliente comprometido
En el desarrollo de software nos interesa tener clientes comprometidos. Es vital para el xito del
proyecto. Un cliente comprometido es aquel que participa en todas las etapas del proyecto,
compartiendo deberes y responsabilidades.