compendio de ingeniería del softwarecotana.informatica.edu.bo › downloads ›...
TRANSCRIPT
4.1 CONCEPTOS DE GESTION
Ingeniería de SoftwareINF - 163
Resumen preparado por Miguel Cotaña1
09/06/2011
2
Un proyecto real !!!
Gestión de Proyectos
Cuando se planifica un proyecto setiene que obtener estimaciones delcosto y esfuerzo humano requeridopor medio de las mediciones desoftware que se utilizan pararecolectar los datos cualitativos acercadel software y sus procesos paraaumentar su calidad.
3
La gestión del proyecto consiste en lautilización de las técnicas yactividades de gestión requeridas paraconseguir un producto de calidad, deacuerdo con las necesidades de losusuarios, dentro de un presupuesto ycon una planificación de tiemposestablecidos previamente.
4
5
Gestión
Construcción
El proyecto
Dimension de un Proyecto
6
Sistema
deseado
Sistema
ofrecido
herramientas
trabajo en
equipo
Liderazgo
organización
de materiales
Diagramación-planos
administración
trabajo físico-intelectual
Dimension de construcción
7
Sistema
deseado
Sistema
ofrecido
herramientas
trabajo colaborativo-cooperativo
diseño
organización de datos
reflexión
Negociación
Resolución de conflictos
intervención
Dimension gestión
Es un esfuerzo temporal
comprometido a crear un producto o
servicio único.
Entre sus características principales:
Temporalidad;
Unicidad;
Progresividad;
Ejecutado por personas;
Limitado a ciertos recursos;
Planificado, ejecutado y
controlado.
Qué es un Proyecto?
8
Tareas críticas en la gestión de proyectos
El número de tareas identificables son
muchas. Sin embargo, 3 son críticas y
que deben ser desarrolladas
correctamente:
Estimación de duración, coste y
esfuerzo necesarios para construir
el producto;
Planificación de tareas a realizar,
asignación de personas, tiempos.
Seguimiento9
Estimación de proyectos
Se define como la predicción de
personal, del esfuerzo, de los costes y
de la planificación que se requerirá para
realizar todas las actividades y
construir todos los productos asociados
con el proyecto.
Uno de los parámetros críticos de la
estimación es determinar su exactitud.
10
11
Estimar
Horas
hombre
Estimar
El
costo
Determinar
Plazos de
entrega
Determinar
Personal
involucrado
Estimación enfoque tradicional
12
Estimar
Horas
hombre
Estimar
Tiempo
total
Determinar
Personal
involucrado
Estimar
El
costo
Determinar
Lineas de
codigo
Establecer
Plazo de
entrega
Estimación: método COCOMO
13
Puntos de
Función sin
ajustar
Puntos de
Función
ajustados
Líneas
De código
Del software
Ratio
Líneas de
Código PF
Estimación: método Punto Función
Larry Putnam, ha apuntado que la
gestión del desarrollo de software
considera la estimación como una
actividad que permite obtener,
principalmente, respuestas a las
siguientes preguntas:
¿Cuánto Costará?
¿Cuánto tiempo llevará hacerlo?14
Razones de difícil estimación
No existe un modelo universal;
Hay muchas personas implicadas en
los proyectos que precisan de
estimaciones;
La utilidad de una estimación
dependerá de la etapa de desarrollo
en la que nos encontremos;
La estimación, a menudo se realiza
superficialmente;
15
16
Las estimaciones claras, completas y
precisas son difíciles de formular;
Las características del Sw y de su
desarrollo hacen difícil la estimación;
Existe tendencia aparente hacia la
subestimación;
Existen malas interpretaciones;
El estimador tiende a reducir en
algún grado, para hacer más
aceptable la oferta.
17
QUÉproducto
CON QUÉsignificado
QUIÉNPersonal
CÓMOProyecto
PARA QUIÉNusuario
Tamaño sw RestriccionesOrdenador
Calidad personal
Req. durac. Proyecto
participación
Calidadrequerida
Tiempo ejec. Resp. Mem.
Experiencia Dilatación comprensi.
estabilidad
Compleji-dad del Sw
Herramientas Organiza-ción
experiencia
Nivel de utilización
Técnicas Prototipado conocimientos
Documen-tación
Programación Modeladoágil
Equipos
Tipo aplicación
Equipo de programación
Matriz de organizació
procedimiento
Requisitos de un buen estimador
No tiene ningún interés, directo ni
indirecto en los resultados del proceso
de estimación:
Formación y experiencia profesional;
Juicio independiente;
Basarse en metodos que pueda ser
explicado, cuestionado, discutido y
auditado por otros expertos;
Usa herramientas de estimación;
Documentar la estimación.18
Salidas del proceso de estimación
¿cuánta gente se necesita?;
¿De qué perfiles?;
¿Cuáles son los riesgos?;
¿Cómo afectan las restricciones
impuestas a las estimaciones?;
¿Cuánto esfuerzo se necesita para
realizar cada fase del ciclo de vida?;
¿Cómo impacta este proceso en el
resto de proyectos de la empresa?;
19
20
¿Cuál será el esfuerzo para
mantener este proyecto?;
¿Cuál será el tamaño del sistema
(lineas de código)?;
¿Cuántos defectos tendrá el
producto?;
¿Cuánta documentación será
generada?;
¿Cuál será el esfuerzo para generar
dicha documentación?.
El espectro de la gestión
La actividad eficaz de la gestión de
proyectos software se enfoca sobre
las cuatro P:
Personal;
Producto;
Proceso;
Proyecto.
21
El SEI ha desarrollado un modelo de
madurez de la capacidad de gestión
de personal (MMCGP), que define:
Reclutamiento;
Selección;
Gestión del desempeño;
Entrenamiento;
Retribución;
Desarrollo de la carrera;
Desarrollo de la cultura de
equipo.
Personal
22
Se clasifican en 5 categorías:
Gestores ejecutivos;
Gestores (técnicos) del proyecto;
Profesionales;
Clientes, ;
Usuarios finales.
Los participantes
23
Weinberg, sugiere un modelo de
liderazgo:
Motivación;
Organización;
Ideas o innovación;
Otra visión, define los rasgos:
Resolución de problemas;
Dotes de gestión;
Incentivos;
Influencia y fomento de la cultura
en equipo,
Líderes de equipo
24
La mejor estructura de equipo
depende del estilo de gestión de cada
organización, del número de personas
que integran el equipo y de sus
grados de habilidad. Los factores:
La dificultad del problema;
El tamaño del programa;
El tiempo que el equipo;
El grado de modularidad;
La calidad y confiabilidad;
La rigidez en fechas de entrega.
El equipo de software
25
El gestor de un proyecto de software
se enfrenta con un dilema desde el
principio de un proyecto de IS. Se
requieren estimaciones cuantitativas y
un plan organizado, pero no dispone
de información sólida.
En consecuencia, se deben examinar
el producto y el problema que se
intenta resolver al inicio del proyecto.
Se debe establecer y acotar el ámbito
del producto.
El producto
26
La primera actividad de gestión :
Contexto. ¿cómo encaja el software
que se desarrollará en el negocio y qué
restricciones se imponen?;
Objetivos de información. ¿qué
objetos de datos se requieren de
entrada?;
Función y desempeño. ¿qué
funciones realiza el software para
transformar los datos en salida?.
Ámbito del software
27
Las actividades del marco de trabajo
que caracterizan al proceso de
software son aplicables a todos los
proyectos de software.
El gestor del proyecto debe decidir
cuál modelo de proceso es más
adecuado para:
1) Los clientes que solicitaron y
personas que realizarán el trabajo;
2) Las características del producto;
3) El ambiente del proyecto.
El proceso
28
La gestión de un proyecto de software
exitoso requiere entender qué puede
salir mal. J. Reel, define 10 señales:
1.El personal de software no
entiende las necesidades de sus
clientes;
2.El ámbito del producto está mal
definido;
3.Los cambios se gestionan mal;
4.La tecnología elegida cambia;
El proyecto
29
5. Las necesidades comerciales
cambian (o están mal definidas);
6. Los plazos de entrega no son
realistas;
7. Los usuarios se resisten;
8. Se pierde el patrocinio;
9. El equipo carece de personal con
las habilidades apropiadas;
10.Los gestores (y profesionales)
evitan las mejores prácticas y las
lecciones aprendidas.30
Se necesita un principio organizador
que escale hacia abajo para
proporcionar planes simples para
proyectos simples. Boehm, realiza una
serie de preguntas.
¿Por qué se desarrolla el sistema?
¿Qué se hará?
¿Cuándo se hará?
¿Quién es el responsable de una
función?
El principio W5 HH
31
¿Dónde están ubicados en la
organización?
¿Cómo se hará el trabajo desde los
puntos de vista técnico y de gestión?
¿Cuánto de cada recurso se necesita?
32