Вы находитесь на странице: 1из 10

UNIDAD I. Metodologa de aprendizaje basada en proyectos.

1.1 Roles y actividades


1.1.1 Administrador de proyecto
El 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. Los recursos
asignados pueden ser recursos humanos, econmicos, tecnolgicos, espacio fsico, etc. En un
proyecto, siempre debe existir un administrador.
No obstante, un administrador puede dirigir ms de un proyecto.
El administrador no es dueo de nada, es slo un administrador temporal de los recursos. Como no
es dueo de nada, debe dejarlos en la misma o mejor condicin de cmo los recibi. Por ello, el foco
de una buena administracin debe estar en el control y coordinacin de los diferentes eventos y
actividades de un proyecto. Adicionalmente, deben crearse las mejores condiciones posibles para
que se realicen las actividades.
Una de las preocupaciones principales para los administradores debe ser el tener una 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.
Algunos de los objetivos de un administrador de proyecto son los siguientes:
Tener el producto a tiempo, bajo presupuesto y con los requisitos de calidad definidos.
Terminar el proyecto con los recursos asignados.
Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a
cumplir sus objetivos particulares. Al final, se cumplir el objetivo general.
Cumplir con xito las diferentes fases de un proyecto, utilizando herramientas de
administracin.
Cumplir con las expectativas del cliente.
Algunos de los objetivos especficos a cumplir por un administrador de proyecto son los siguientes:
Comenzar y terminar cada actividad de acuerdo a lo planificado.
Lograr el mejor uso de los recursos disponibles.
Observar cada actividad para detectar y resolver inconvenientes.




A continuacin se muestra el conjunto de actividades a realizar por el administrador de proyecto
para lograr cumplir con xito las metas definidas.
a. Desarrollo eficiente de reuniones: El administrador de proyecto est a cargo de las
reuniones y presentaciones entre el grupo y con los clientes.
Debe conducir la reunin usando el protocolo establecido.
Debe cuidar de todos los aspectos de la reunin (layout de la sala, luces, sillas, mesas,
computadores, proyeccin y sonido, pizarra, lpices, material que se entrega, etc.). Mida el
tiempo y comprelo con lo planificado, para as maximizar la eficiencia.
Cada reunin debe ser evaluada. De ser necesario, deben tomarse acciones correctivas.
Promueva reuniones de integracin (desayunos, comidas, coffee breaks, etc.), donde el
grupo pueda intercambiar puntos de vista y experiencias, creatividad y espontaneidad
b. Desarrollo organizacional:
Conduzca reuniones y seminarios cuando el grupo determina los prximos puntos:
Visin.
Misin.
Metas.
Objetivos.
Actividades.
c. 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 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.
d. En general:
Realizar reuniones generales y seminarios de evaluacin y planificacin.
Realizar reuniones de evaluacin con cada rol.
Obtener informacin sobre el estado el proyecto para el equipo y para el cliente.


1.1.2 Analista
La palabra anlisis se refiere a una caracterstica tpicamente relacionada con la inteligencia
humana. Esta se refiere a la habilidad de poder estudiar un problema de una complejidad
determinada, descomponiendo el problema en subproblemas de menor complejidad. De esa forma,
la solucin del problema completo se obtiene como la suma de las soluciones de los subproblemas
de menor complejidad.
Lo anterior indica que la fase de anlisis en un proyecto de construccin de software se refiere a la
especificacin de un problema como la suma de subproblemas de menor complejidad. Como el
experto en el problema es el cliente, se hace necesario trabajar junto a l para realizar la
especificacin correctamente. Los miembros del grupo que trabajan con el cliente para realizar el
anlisis y especificacin del sistema a construir son precisamente los analistas.
Para que el trabajo de los analistas tenga sentido para todos los integrantes del grupo, se hace
necesario ponerse de acuerdo en la forma como se realizar la especificacin, as como la forma
como el resto del grupo la entender. Esto sugiere el uso de un estndar para realizar la fase de
anlisis del problema. En el caso del estndar de la ESA, el anlisis se divide en dos fases:
especificacin de requisitos de usuario y especificacin de requisitos de software. Los analistas
deben liderar ambas fases.
Una de las razones ms frecuentes del fracaso de un desarrollo de software es la de realizar un
anlisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y especificar el sistema que desea
el cliente, los desarrolladores construyen sistemas que no cuentan con las caractersticas que el
cliente desea. Ese error se repite una y otra vez, y se debe bsicamente a la inexperiencia del grupo
de desarrolladores.
Actividades:
Entrevistar al cliente, ayudndole a identificar sus necesidades.
Verificar si los requisitos especificados son los correctos.
Definir una estructura bsica del sistema que incluya fuentes de informacin, mdulos de
procesamiento de informacin, y resultados esperados.
Realizar el anlisis de los requisitos. Establecer una estructura bsica inicial del sistema.
Analizar la estructura bsica del sistema.
Generar los diagramas de la arquitectura.
1.1.3 Diseadores
Es el encargado de generar el diseo del sistema. Entre sus funciones est:
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).
En cada disciplina de la ingeniera, el diseo acompaa el enfoque disciplinado que se utiliza para
inventar la solucin de un problema, entregando as un camino entre los requisitos y la
implementacin. En ingeniera de software, el propsito del diseo es la construccin de un sistema
que cumpla con los siguientes aspectos:
Satisfaga una especificacin funcional dada.
Cumpla con las limitaciones del medio receptor del sistema.
Cumpla requisitos implcitos y explcitos de rendimiento y uso de recursos.
Satisfaga criterios de diseo implcitos y explcitos en la forma del artefacto construido.
Satisfaga restricciones del mismo proceso de diseo, tal como su duracin y costo, o las
herramientas disponibles para realizar el diseo.
Objetivos
El propsito del diseo es el de crear una estructura interna limpia y relativamente simple, tambin
llamada a veces una arquitectura. Un diseo es el producto final del proceso de diseo. As, una de
las metas en el diseo de software es derivar una arquitectura del sistema. Esta arquitectura sirve
como un marco desde el cual se conducen ms actividades de diseo detallado.
Las buenas arquitecturas de software tienden a tener algunos atributos comunes. Entre ellos se
pueden mencionar los siguientes:
Se encuentran construidos en niveles de abstraccin bien definidos, provistos a travs de
una interfaz bien definida y controlada, y construida sobre facilidades igualmente bien
definidas y controladas en niveles de abstraccin inferiores.
Existe una separacin clara de preocupaciones entre la interfaz y la implementacin de cada
nivel, haciendo posible cambiar la implementacin de un nivel sin violar las suposiciones
que hicieron los clientes.
La arquitectura es simple, comportamiento comn se obtiene a travs de abstracciones y
mecanismos comunes.
Actividades:
Descomposicin de subsistemas
Definir la administracin de acceso a recursos globales
Seleccionar una tcnica de administracin de almacenamiento de datos.
Interactuar con los programadores para seleccionar el lenguaje y paradigma apropiado
Asignacin de subsistemas a procesadores
Administracin de la concurrencia.
Seleccin de estrategias de control
1.1.4 Programadores
Los programadores deben convertir la especificacin del sistema en cdigo fuente ejecutable
utilizando uno o ms lenguajes de programacin, as como herramientas de software de apoyo a la
programacin.
El xito del desarrollo de software depende grandemente de conocimiento. Este conocimiento no
slo corresponde a habilidades de programacin y de administracin de proyectos, sino que a una
percepcin y entendimiento de los ltimos desarrollos de la industria del software. En los mercados
actuales, rpidamente cambiantes y altamente competitivos, se hace necesario conocer los ltimos
desarrollos, quien da soporte, y como pueden beneficiar al proyecto y a la organizacin. A travs de
este conocimiento es que la organizacin genera un camino hacia el xito futuro.
Objetivos
Uno de los principales objetivos de los programadores durante su trabajo debe ser la de reducir la
complejidad del software. Algunos de los beneficios que implican la reduccin de la complejidad del
programa son:
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.
Adicionalmente, otros objetivos importantes son:
Reducir el tiempo de codificacin, aumentando la productividad del programador.
Disminuir el nmero de errores que ocurren durante el proceso de desarrollo.
Disminuir el esfuerzo de corregir errores en secciones del cdigo que se encuentran
deficientes, remplazando secciones cuando se descubren tcnicas ms confiables,
funcionales o eficientes.
Disminuir los costos del ciclo de vida del software.
Para alcanzar estos objetivos, es importante escoger las herramientas de desarrollo apropiadas. De
eso depender en parte poder alcanzar los objetivos, y por lo tanto, el xito del proyecto.
Es claro que para elegir las herramientas adecuadas, es necesario conocer el ambiente donde el
software va a correr.
Actividades
Explorar los diferentes ambientes en que el sistema puede ser desarrollado Interactuar
con los analistas y diseadores
Explorar los diferentes lenguajes disponibles para el ambiente seleccionado
Interactuar con los diseadores
Explorar diferentes herramientas de desarrollo (compiladores, depuradores, etc.)
disponibles para el lenguaje seleccionado
Explorar los distintos estilos de codificacin que pueden ser utilizados en el lenguaje
seleccionado
Realizar la codificacin del sistema
Interactuar con los ingenieros de testeo
Interactuar con el administrador de la configuracin
Realizar los cambios solicitados al cdigo
Hacer la documentacin del cdigo
Apoyar al ingeniero de testeo
Reunirse con otros miembros del equipo de programadores
Realizar revisiones personales
1.1.5 Tester
El desarrollo de un sistema de software requiere la realizacin de una serie de actividades de
produccin. En dichas actividades existe la posibilidad de que aparezcan errores humanos. Dichos
errores pueden empezar a aparecer desde el primer momento del proceso. Por ejemplo, los
requisitos del sistema pueden ser especificados en forma errnea o imperfecta. Por ello, el
desarrollo de software considera una actividad que apoye el proceso de deteccin y eliminacin de
los errores y defectos del sistema en construccin. El objetivo del rol de tster es precisamente
realizar dichas tareas.
El tster es el encargado de asegurar la calidad de cada uno de los productos (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).

Objetivos
El objetivo principal de la labor de tster es el de disear tests que en forma sistemtica, permita
eliminar diferentes clases de errores, realizando esto con la mnima cantidad de tiempo y esfuerzo.
Los objetivos especficos en la labor de un tster son los siguientes:
Aplicar mtodos para disear casos de tests efectivos.
Construir buenos casos de tests que tengan altas probabilidades de encontrar errores an
no descubiertos.
Demostrar que las funciones del sistema parecen estar funcionando de acuerdo a sus
especificaciones.
Proveer una buena indicacin de la confiabilidad del software y algunas indicaciones
de la calidad del software.
Actividades
Participacin en el proceso de especificacin del sistema
Interaccin con el diseador
Realizar los tests, apoyado por los programadores
Informar sobre los resultados obtenidos


1.1.6 Aseguradores de la calidad
En la actualidad, los factores dominantes en la administracin de proyectos de software son los
tiempos y costos de desarrollo. Existen buenas razones para ello. Los tiempos y costos de desarrollo
son con frecuencia, muy grandes. Por ello, la administracin se ha concentrado en tratar de resolver
dichos problemas. Sin embargo, existe un gran peligro en esto. En la medida que crece la presin
por cumplir con las fechas estipuladas, y reducir los costos, es la calidad del producto la que sufre.
Cuando se acelera el desarrollo de un sistema que est atrasado, generalmente se corta todo lo que
no se considere esencial, usualmente cortando las actividades de verificacin y testeo, resultando
en un producto de calidad reducida.
Se hace necesario encontrar una nueva ecuacin para el desarrollo de software. No debe ser
simplemente producto de software = a tiempo + dentro de los costos. Debiese ser producto de
software = calidad + a tiempo + dentro de los costos. Para ello, debe existir el convencimiento
individual y de la gerencia de considerar la calidad 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. Tpicamente, dichos atributos se encuentran definidos en la forma de
un estndar, el
Actividades:
Revisar los documentos de requisitos de usuario y de software
Revisar el plan de administracin del proyecto
Revisar el plan de testeo
Revisar la fase de diseo arquitectnico
Revisar la fase de diseo detallado
Revisar las polticas de control de cambios, control de errores y control de la configuracin
Revisar la documentacin
1.1.7 Administrador de configuracin
La administracin de la configuracin es una disciplina que tradicionalmente se aplica al desarrollo
de sistemas de hardware, al desarrollo de elementos de hardware o sistemas de
hardware/software. La administracin de la configuracin de software corresponde a la
administracin de la configuracin aplicada a un sistema, o a partes de un sistema,
predominantemente correspondiente a software. Su aplicacin, en conjunto con otras disciplinas,
lleva al desarrollo de sistemas en forma ordenada y estructurada.
La administracin de la configuracin es una disciplina que aplica direccin y vigilancia tcnica y
administrativa a:
Identificar y documentar las caractersticas funcionales y fsicas de items de configuracin.
Auditar los items de configuracin para verificar cumplimiento de especificaciones, control
de interfaces y documentos, as como otros requisitos adicionales que pueda definir el
contrato.
Controlar cambios a los items de configuracin y su documentacin relacionada.
Registrar y reportar informacin necesaria para administrar items de configuracin en
forma efectiva, incluyendo el estatus de cambios propuestos y el estatus de implementacin
de cambios aprobados.
Mantener el repositorio del proyecto actualizado con las ltimas versiones de todos los
entregables del proyecto.
Administrar el software utilizado para el control de versiones.
Definir y controlar perfiles de acceso a los archivos del proyecto.
Velar por la completitud y exactitud del repositorio del proyecto.
Los problemas de software ms frustrantes son frecuentemente ocasionados por una pobre
administracin de la configuracin. Los problemas son frustrantes debido a que requieren tiempo
para arreglarlos, y usualmente ocurren en el peor momento, y son totalmente innecesarios.
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.
Preparar el Plan de Administracin de la Configuracin de Software de acuerdo al estndar en uso
Las tareas iniciales son identificar las lneas base que sern usadas en el proyecto, y los items que
sern parte de cada lnea base. Este proceso se llama identificacin de la configuracin. En el sentido
de la administracin de la configuracin, una lnea base es un documento, o un conjunto de ellos,
formalmente designados y fijados en el tiempo. Por ello, una lnea base es un repositorio oficial del
producto, y contiene la versin ms reciente.
Para alcanzar esta meta, el control de la configuracin de software provee el mecanismo
administrativo para precipitar, preparar, evaluar y aprobar o reprobar el procesamiento de
propuestas de cambio. Incluye 3 actividades bsicas:
Actividades:
Establecer y disear la documentacin requerida para formalmente precipitar y definir un
cambio propuesto a un sistema de software (Propuesta de Cambio de Ingeniera, PCI).
Formar un cuerpo organizacional para formalmente evaluar y aprobar o reprobar un cambio
propuesto a un sistema de software (Cuerpo de Control de Cambio, CCC).
Realizar los procesos para controlar cambios a un sistema de software.
Realizar RTFs y/o auditorias de configuracin de software. stas son los medios para
asegurar que el cambio se implement correctamente.
Registrar y reportar informacin requerida para administrar items de configuracin
eficientemente.
1.1.8 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.
El objetivo principal del rol de documentador es el de mantener la informacin generada durante el
proceso de desarrollo. Como objetivos especficos se tienen los siguientes:
Permitir el almacenamiento y recuperacin de la documentacin de los procesos y
productos ms recientes durante el desarrollo, manteniendo as la informacin al da.
Mantener la consistencia en la apariencia y estructura de los documentos, facilitando su
almacenamiento, recuperacin e intercambio, no permitiendo el almacenamiento de
documentos con formatos diferentes.
Asegurarse que los cambios que necesitan hacerse en el sistema sern reflejados en la
documentacin correspondiente.
Elaborar, almacenar y permitir la recuperacin de las actas y registros generados durante
las reuniones de revisin, los que constituyen parte del proceso de documentacin.
Construir el manual de usuarios del sistema, MUS, que contempla los aspectos de uso del
sistema.
Actividades:
El documentador debe disear y construir un repositorio de informacin compartido, donde se
almacenar la documentacin.
Mantener el repositorio de informacin. El documentador debe agregar todos los nuevos
documentos generados y remplazar los documentos que fueron modificados en el proceso de
desarrollo.
Especificar el formato que ser usado para elaborar la documentacin. El formato especificado debe
contemplar al menos lo siguiente:
Estructura del documento.
Tipos de letra y colores a usar en cada documento.
Distribucin de los elementos en el documento (texto, imgenes, dibujos, logos, etc.).
Caractersticas de las figuras, imgenes y dibujos consideradas en el documento.
Asegurarse que los documentos mantienen el estndar de documentacin definido para el
proyecto antes de incluirlos en el repositorio.
Durante las reuniones de revisiones, el documentador elaborar las actas de la reunin.
Estos documentos sern usados luego por el ingeniero de validacin y verificacin.
Elaborar el manual de uso del sistema, MUS.

1.2 Fases de un Proyecto
Inicio: La fase de inicio puede ser corta. Sin embargo, es esencial en la autorizacin y la
definicin del alcance del proyecto. Esta fase incluye la definicin del proyecto, la
produccin de una primera descripcin del producto, la generacin de una carta del
proyecto y el anlisis de las necesidades del negocio.
Planificacin: La fase del plan prepara el equipo para un rendimiento eficiente durante la
ejecucin. Es donde investigan y planifican el proyecto. Esta fase puede consistir en elaborar
un plan de desarrollo del software, estableciendo las estimaciones del proyecto y creando
un plan de aseguramiento de la calidad. Tambin puede implicar el desarrollo de un plan de
etapas de entregas, requerimientos, documentos de diseo detallado, un plan de gestin
del cambio y gestin de riesgos. Adems, la arquitectura del producto ser acordada, el
personal comenzar el aumento gradual y prototipos desarrollados. La realizacin de
revisiones con tus expertos en la materia son cruciales en esta etapa.
Ejecucin: La fase de ejecucin consiste en la coordinacin de personas y otros recursos
para llevar a cabo el plan. Es el lugar donde se realiza el trabajo real. El noventa por ciento
o ms de los esfuerzos del proyecto se gastan durante esta fase, y se completa cuando se
cumple la meta del proyecto. La fase de ejecucin puede constar de las siguientes acciones:
desarrollo del cdigo, creacin de casos de prueba y el establecimiento de la documentacin
del usuario. Los planes de control de cambios y la gestin de riesgos se seguirn y se
realizarn los exmenes tcnicos. El producto se puede liberar en etapas que se
proporcionan, incorporando una liberacin por etapas en el proceso de planificacin.
Control: La fase de control se produce en conjunto con la fase de ejecucin. Durante esta
fase, se hace un seguimiento del trabajo. Esto garantiza que la calidad de la obra siga siendo
elevada y mantiene el proyecto en marcha. Esta fase puede implicar la realizacin de
pruebas y corregir los posibles defectos. Durante esta fase, es imperativo que el equipo se
mantenga enfocado y comunique el estado del proyecto y los hitos futuros regularmente.
Cierre: La estrecha fase suele ser la fase ms corta de un proyecto, pero no menos
importante que las otras. Esta fase establece el cierre formal del proyecto, revisa los xitos
y los fracasos con miras a mejorar el prximo. La estrecha fase puede consistir en comunicar
el archivo del proyecto, captura de lecciones aprendidas y evaluacin de la ejecucin contra
el plan del proyecto.

Вам также может понравиться