Desarrollo de Software a gran escala. Sesión 2: Administración de Proyectos de Software

Transcripción

1 Desarrollo de Software a gran escala Sesión 2: Administración de Proyectos de Software

2 Porque administrar un proyecto de Software Asegurar el alcance de los objetivos del proyecto Maximizar uso de recursos (diferentes proyectos a la vez) Entorno cambiante -> Riesgos Lograr un proyecto exitoso (Tiempo, Dinero, Objetivos)

3 Técnicas y métodos involucrados en la administración de proyectos de software Gerencia de proyectos: PMI, SCRUM, etc. Técnicas: Gestión de cambios Gestión de riesgos Administración (Por objetivos, por escenarios, etc.)

4 Herramientas para Administrar un proyecto de Software Plan de Proyecto Cronogramas de trabajo Reuniones de seguimiento Actas e informes Control de cambios

5 Plan de Proyecto de Software Estimación de tamaño y esfuerzo Administración de Cambios Gestión de configuración Asignación de tiempos y tareas Ubicación de recursos Identificación y administración de los riesgos del proyecto

6 Planeación del proyecto La planificación tiene como objetivo definir las metas, individuales y de equipo, a alcanzar en un espacio de tiempo. Principales problemas: Cuando se tiene la presión del cliente o de la misma compañía proveedora, se tiende a eliminar de la planificación tareas clave, como las pruebas y el desarrollo de módulos de administración o a subestimar los requerimientos existentes para obtener una planificación de menor tiempo. Las planificaciones excesivamente optimistas producen en los equipos un efecto negativo, lejos de ejercer una presión positiva sobre los individuos y el equipo, genera una pérdida de la motivación en el logro de los objetivos ya que de antemano se reconoce que la meta no se alcanzará.

7 Estimación de esfuerzo Es una tarea clave la cual consiste en estimar el tamaño de la solución a proveer y asociado a ello estimar el esfuerzo: Número de personas-mes necesarios para alcanzar los objetivos del proyecto. Principales problemas: Los clientes de soluciones de software no le dan importancia a la estimación y delegan en el proveedor la responsabilidad de establecer si es factible o no lograr el alcance con el tiempo y presupuesto planteado por el cliente. Los proveedores no cuentan con la información necesaria para hacer una adecuada estimación del tamaño al comienzo del proyecto No se sigue un método riguroso para calcular el esfuerzo requerido

8 Gestión de Cambios Consiste en evaluar y ajustar constantemente el plan de proyecto de acuerdo a las situaciones que impacten objetivos, tiempo y recursos. La adopción de un cambio puede significar la modificación del cronograma inicialmente definido, la disminución del alcance del proyecto o la necesidad de ampliar el presupuesto destinado para la ejecución del proyecto. Principales problemas: No se da visibilidad al cliente del impacto en el Alcance, Cronograma y Presupuesto del proyecto El cliente no conoce las implicaciones de los requerimientos mal especificados o especificados superficialmente. En el caso que el cambio se deba a errores u omisiones del proveedor, será el proveedor quien deba asumir el costo.

9 Gestión de configuración El objetivo de la gestión de la configuración es mantener la integridad de los productos que se obtienen a lo largo del desarrollo de los sistemas de información, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del software disponen de la versión adecuada de los productos que manejan. Elementos comunes a gestionar: Ejecutables y código fuente Modelos de datos Especificaciones de requisitos Plan de pruebas La gestión de configuración facilita el mantenimiento del sistema, aportando información precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementación de un cambio, tanto evolutivo como correctivo.

10 Definición del Plan de Gestión de Configuración Los aspectos que debe contemplar el plan son: Identificación de todos los productos que deben ser controlados, su clasificación y relaciones entre ellos, así como el criterio o norma de identificación. Ubicación y localización de los productos. Definición del ámbito y alcance del control de la configuración, describiendo los procesos incluidos en él. Definición de las reglas de versionado de los productos y los criterios de actuación para cada caso, teniendo en cuenta el motivo por el cual se realiza el cambio de versión. Definición del ciclo de estados para cada tipo de producto y los criterios de trazabilidad entre los mismos. Descripción de funciones y responsabilidades. Identificación de la información necesaria de control para auditoría.

11 Consideraciones prácticas sobre la fuentes de cambios y la mantenibilidad del sistema El usuario final es la principal fuente de cambios sobre la funcionalidad liberada. Realizar liberaciones incrementales a producción basadas en la priorización de las necesidades de negocio agiliza la aceptación de los cambios. La arquitectura de software engloba las decisiones técnicas sobre la aceptación o no de los cambios.

12 Asignación de tiempos y tareas (incluyendo roles) Consiste en designar los miembros del equipo con sus roles respectivos en el desarrollo del proyecto, identificándoles las tareas y los tiempos asignados para ellas. Las actividades del ciclo de vida deberán ser asignadas al equipo de trabajo del proyecto según dos criterios fundamentales: La experiencia previa, que le permitirá a cada miembro del equipo ser altamente productivo en la ejecución de la tarea y los gustos de cada uno de los miembros de equipo, lo cuál le facilitará las labores de investigación en áreas específicas que desconozca de la tarea. Con esto se tendrá como resultado un equipo productivo, especializado y altamente motivado en la ejecución del proyecto. Principales problemas: No se hace uso de una metodología que incluya las actividades que garantizarán la construcción de la solución dentro de los criterios y condiciones definidas por el cliente. Se asignan los roles y responsabilidades del equipo sin tener en cuenta el gusto y la experiencia previa de sus integrantes

13 Roles y Responsabilidades Comunes Jefe de Proyecto: Asignar los recursos, gestionar las prioridades, coordinar las interacciones con los clientes y usuarios, mantener al equipo del proyecto enfocado en los objetivos. También establecer un conjunto de prácticas que aseguran la integridad y calidad del proyecto. Supervisará el establecimiento de la arquitectura del sistema, la gestión de riesgos y la planificación y control del proyecto. Analista de Sistemas: Capturar, especificar y validar requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaborar el Modelo de Análisis y Diseño. Colaborar en la elaboración de las pruebas funcionales y el modelo de datos. Analista Programador: Construir prototipos. Colaborar en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario. Ingeniero de Software: Gestión de requisitos, gestión de configuración y cambios, elaborar el modelo de datos, preparar las pruebas funcionales, elaborar la documentación. Elaborar modelos de implementación y despliegue.

14 Otros Roles Arquitecto de Software Jefe de Desarrollo (líder de desarrollo) Analista de Pruebas / Tester Ingeniero de Calidad (líder SQA) Implementador Administrador base de datos (DBA)

15 Como organizar un equipo? Cual será la dependencia de la estructura organizacional de la empresa (casa de software)? Cuantos miembros en el equipo? Cuales Skills se requieren? Se necesitan todos en todo momento? Cual será la estructura de gobierno y de gestión del equipo?