Administración y Gestión de Proyectos de Software

Transcripción

1 Administración y Gestión de Proyectos de Software 2do. Cuatrimestre 2005 Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur Integrantes de la Cátedra: Profesor: Sergio Martig srm@cs.uns.edu.ar Asistente: Carla Mendes Kalo kmca@cs.uns.edu.ar Ayudantes: Enrique Gnocchini Hugo Peralta Pamela Ranni

2 Contenidos Proyectos de Software Modelos y Métricas Modelos de Costos Planificación de Proyectos Control de Proyectos Calidad - Normas ISO Auditoría - Organización - Legislación Bibliografía Principles of Software Engineering Management - Tom Gilb Controlling Software Projects - Tom de Marco Software Metrics - Fenton & Pfleeger Effective Project Management - Robert Wysocki, R.Beck, D.Crane Dirección de Proyectos Informáticos - Pham Thu Quang, Jean-J.Gonin Ingeniería de Software Un Enfoque Práctico - Roger Pressman Manual de Derecho Informático - Bibiana Luz Clara Information Systems Control and Audit - Ron Weber

3 Cursado de la Materia Dos Parciales - Un recuperatorio para cada parcial. Primer Parcial: 4 de octubre. Recuperatorio Primer Parcial: 18 de octubre. Segundo Parcial: 17 de noviembre. Recuperatorio Segundo Parcial: 29 de noviembre. Dos Proyectos: las fechas de entrega son el 20 de septiembre y el 22 de noviembre. Qué es un proyecto? Cualquier actividad que dé como resultado un producto o un entregable. Proyecto de SW: grandes sistemas, programación de un módulo. Comienzan con el enunciado de un problema. Evaluación: El producto soluciona el problema del usuario? Está el usuario satisfecho con el proceso? Está la gerencia satisfecha con el producto/proceso? Está el equipo de desarrollo satisfecho?

4 Fracasos: Al comienzo No despegan correctamente - Sin planificación. Proyectos avanzan rápidamente al 90% y siempre se quedan ahí. Qué es planificar? Conocer anticipadamente a donde se va a ir. Cómo se va a hacer para llegar hasta ahí. Cómo se va a hacer para probar que se esta ahí. Fracasos: En el desarrollo Análisis y diseño mal documentados. Asignación confusa de responsabilidades. Falta de planificación y organización de recursos requeridos. Codificación prematura. Falta de revisiones (gerenciales) y walk-through (técnicos). Falta de estándares de desarrollo - Deserciones - Técnicas de Fuerza Bruta.

5 Fracasos: Al final Aplicaciones entregadas sin suficientes pruebas. Aplicaciones sin performance. Altos costos de mantenimiento. Cancelación de Proyectos: Falta de fondos Cambios en el contexto Deserción de elementos claves Desastre técnico Proyectos Exitosos Claro comienzo - Plan detallado. Criterios de medición aceptables. Monitoreo cercano durante el desarrollo. Documentación clara - Revisiones frecuentes. Procedimientos para detección de problemas. Costo razonablemente cercano al estimado.

6 Aclaración: Años Hombre Es una unidad de medida para el esfuerzo. 1 Año-Hombre: El trabajo que puede realizar una persona en un año. En general, se asume que una persona trabaja 160 horas mensuales. 1 Año-Hombre = 160 horas/mes x 12meses = 1920 horas 5 Años-Hombre: El trabajo que puede realizar un persona en 5 años. Ejemplo: Corporate Information System (CIS) El proyecto se canceló. Tiempo: 5 años. Presupuesto: 80 años-hombre. Se habían hecho todas las cosas bien: Se consultaron publicaciones. Se aceptó la necesidad de un sistema centralizado. Se contrató consultora para el estudio de factibilidad (15 años-hombre). Se utilizó hardware de última tecnología y software de base de datos. Se pagaron varios millones de dólares por encima del presupuesto. Se utilizaron las últimas técnicas de programación estructurada.

7 CIS: Motivo del Fracaso El proyecto funcionaba. Todos los programas ejecutaban correctamente. Se pedía tiempo para optimizar performance. Se necesitaba alimentar con transacciones diarias. La actualización de una sola transacción podía durar 20 minutos. Se estimaba 2 años el esfuerzo para agregar una fábrica. El plan de crecimiento era abrir una cada seis meses. Conclusión: No tuvieron un nuevo sistema de administración y se perdieron 5 años con respecto a sus competidores. CIS: Prevención del Fracaso Fracaso para determinar y controlar atributos críticos del proyecto. Fracaso para encontrar una arquitectura adecuada para los AC. Fracaso para hacer evolucionar un sistema basado en incrementos. Atributo Crítico: calidades y recursos que pueden causar que el sistema colapse si superan determinados límites (peor caso aceptable). Atributos críticos en el CIS: Performance de la operativa diaria, Habilidad para incorporar nuevas unidades de negocio.

8 CIS: Atributos Críticos - Especificación Capacidad de Trabajo: la capacidad de trabajo debe ser suficiente para administrar el trabajo diario normal en un día de oficina normal. Peor caso: 4 segundos en promedio por transacción. Nivel planificado(inicial): menos de un segundo por transacción. Nivel planificado (si \#trans.$>$ diarias): 0.2 seg.p/ trans. La presunción fue que iba a haber suficiente capacidad de procesamiento. Como no se especificó como requerimiento formal, nadie se preocupó. CIS: Atributos Críticos - Especificación Adaptabilidad: el sistema deberá ser capaz de integrar nuevas unidades de negocio, de tal manera que el sistema no sea motivo de retraso. Peor caso: las principales unidades de negocios nuevas, ej: una fabrica, deberán ser integradas en un plazo de 6 meses y con un esfuerzo máximo de 10 programadores /analistas o 5 años-hombre. Nivel planificado: las principales unidades de negocio deberían agregarse o eliminarse del sistema en menos de 6 meses de trabajo de esfuerzo calificado.

9 Principios Iniciales de Administración Todos los atributos críticos (AC) se deben especificar claramente. El diseño debe satisfacer todos los AC simultáneamente. Todos los AC deben ser especificados en términos testeables medibles. Se debe identificar el peor caso. Nunca intentar entregar grandes sistemas complejos en big-bang. No creer ciegamente en cualquier método. Usar el propio y el sentido común. Si no se sabe lo que se está haciendo, no hacerlo en gran escala!! Cuestiones Gerenciales Tareas del Gerente: Definir objetivos. Crear, evaluar y seleccionar alternativas para alcanzar esos objetivos. Controlar la implementación de la alternativa seleccionada. Los gerentes confían en proveedores, expertos de ventas, consultores. La red de comunciación entre gerentes, problem-solvers, técnicos y clientes a cerca de objetivos, planes y alternativas: es inadecuada. Los gerentes deben gerenciar!!!

10 Problemas Multidimensionales La mayoría de las decisiones son multidimensionales. Problema de la sobre-simplificación: no encontrar solución adecuada. Podemos olvidar algunos factores críticos, ellos no se olvidarán de nosotros. Necesidad de la gerencia de administrar múltiples objetivos. Los entornos dinámicos requieren herramientas pensantes en lugar de dogmas no pensantes. Derecho a Problemas de Comunicación: Saber que se espera de Ud. Aclarar aspectos con cualquier persona en la organización. Iniciar definiciones más claras de objetivos y estrategias. Obtener objetivos presentados en formato medible y cuantificado. Cambiar objetivos y estrategias para lograr mejor performance. Probar nuevas ideas para mejorar la comunicación.

11 Problemas de Comunicación: Derecho a Fracasar al probar y corregirlo rápidamente. Desafiar constructivamente objetivos y estrategias de alto nivel. Ser juzgado objetivamente en base a objetivos medibles. Ofrecer ayuda constructiva} a colegas para mejorar la comunicación