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.